Sonnensensor

[gnampf]

wenn ich es richtig sehe gibt es bisher eigentlich noch keinen "bezahlbaren" (<100 Euronen) Sonnen/Helligkeitssensor, der dann auch noch für den Außeneinsatz taugt, oder?
Besteht bedarf an einer Selfbus-Lösung? Was mir vorschweben würde:
- Sensor als batteriebetrieben Funkmodul
- Atmega328 (z.B. Arduino Pro Mini, Mega168 sollte auch reichen)
- IR11145
- RFM69
- Betrieb mit 2xAA(A)
- passende Firmware
und als Verbindung zum KNX dann
- TS-ARM-Modul
- RFM69
- passende FIrmware + KNXPROD

Der eigentliche Sensor läuft bei mir schon im Testbetrieb, aber noch ohne Empfänger mit KNX-Anschluß. Wenn da aber allgemein Interesse besteht könnte ich versuchen das entsprechend universeller aufzubauen, incl. Anleitung. Wenn kein Interesse besteht spar ich mir die Arbeit natürlich lieber Prinzipiell wäre die Anbindung mehrerer Sensoren gleichzeitig über ein "Gateway" möglich... und z.B. auch die Anbindung von Bodenfeuchtesensoren (ebenfalls per Funk).

Kosten Gateway:
- TS-Arm-Modul
- RFM69 3,60 EUR bei Pollin
- Antenne ab wenigen ct

Kosten Sensor:
- ATmega als Arduino-ProMini-Board etwa 5 EUR bei ebay
- Sonnensensor als Seeed Groove Sunlight 9,60 bei Reichelt
- Batteriehalter 0,64 EUR bei Reichelt
- Gehäuse 3,75 EUR bei Reichelt
- "Glas"kuppel für Sonnensensor 4,90 EUR bei stall.biz (optional, ginge wohl auch durchs transparante Plastikgehäuse)

eigene Platinen wären wohl im ersten Step nicht nötig und nicht vorgesehen. Auf dem Bus würde der Sensor einfach den Helligkeitswert in "Lux" (wie genau der ist kann ich mangels anderer Meßmöglichkeiten nicht sagen) ausgeben. WÜrde also erstmal keine eigene Verschattungssteuerung enthalten. Keine Ahnung was die kommerziellen Sensoren da anbieten.
Ob das ganze am Ende dann länger hält als die Homematic IP Sonnensensoren kann ich wohl erst in 2 Jahren sagen... so lange haben die ja in etwa auch durchgehalten.

[Doumanix]

Hi gnampf,

also prinzipiell gab / gibt's da schon was: https://selfbus.myxwiki.org/xwiki/bin/v ... ombisensor - aber halt nur, wenn man an ein KNX Kabel ran kommt.

Außerdem hatten wir (Mario und ich) auf Slack kurz über die Anbindung eines BH17xx an den ARM diskutiert (siehe: https://selfbus.slack.com/archives/C020 ... 6085035400).

Ich finde die Idee, ein sehr stromsparendes Sendemodul zu haben und einen Selfbus-Empfänger auf der Gegenseite, der das sauber auf den KNX-Bus bringt, sehr interessant. Es muss es ja gar nicht immer Batteriebetrieben sein, ggf. könnte man auch mit einem kleinen Platinennetzteil von 230V auf ein Spannungsniveau kommen, mit dem man einen Sender betreiben könnte? Könnte die eine oder andere Lücke im KNX Netz schließen.

Blöde Frage: Warum der Atmega328? Was zeichnet den besonders aus?

Grüße
Christian

[gnampf]

ah, ok, den alten hatte ich nicht gefunden, aber mit dem alterm Prozessor wohl auch eher nicht mehr so sinnvoll.
der BH1750 wäre deutlich günstiger, aber der Helligkeitsbereich ist nur halb so gross, und kein UV. Und der 1145 liegt schon hier

Die Funk-Kommunikation könnte man sicherlich auch mit Netzteil betreiben. Für Batteriebetrieb wäre es bisher als reiner Sender vorgesehen. Wacht regelmäßig alle paar Minuten auf, macht die Messung, übertrögt die Werte und wartet auf ACK vom Empfänger, ggf. Retry. Danach dann wieder Schlafenszeit. Und während dem Schlaf ist halt auch der Empfänger aus um Strom zu sparen. Für sowas wie reine Taster ließe sich das 1:1 umsetzen, wenn er aber z.B. eine LED haben soll müsste man für den Netzbetrieb den Empfangsmodus aktivieren und die Möglichkeit schaffen von der "Basis" aus zu senden.

Warum der 328er? Weil er mehr Speicher als der MEga88 hat und hier rumlag Beim Sonnensensor haben mir die 8l abzüglich Arduino-BL knapp nicht gereicht. Prinzipiell könnte das jeder Prozessor mit I2C für den Sensor und SPI für den RFM erledigen... oder auch einfach jeder mit genug IO-Ports, denn I2C + SPI sind jetzt kein Hexenwerk. Solte für Batteriebetrieb halt brauchbare Sleepmodes mit niedrigem Verbrauch mitbringen. Bei meinem ersten Test-Feuchtesensor haben gebrauchte AAA Batterien knapp 'nen Jahr gehalten, bei Meßwertübermittlung so alle 2-3 Minuten. Im Sleep liegt das Teil bei etwa 6µA. Betrieb mit Akkus wäre auch kein Problem, außer das die ggf. tiefentladen werden.

[Doumanix]

Was mir halt im Kopf rum ging: auch der LPC1115 hat ja Sleep-Modi ... gäbe es denn nicht ne Möglichkeit ein Modul zu bauen, was als Busmodul gleich fungiert, wenn es am Bus hängt oder wahlweise auch als batteriebetriebenes Funkmodul betrieben werden kann?
Oder ist da der ARM einfach nicht dazu geeignet?

edit: denn wenn man das mal mit dem ARM gelöst hätte, könnte man ja auch andere Sensoren funken lassen ...

[gnampf]

prinzipiell würde es wohl auch mit dem ARM gehen, wenn er nicht vom Quartzoszi betaktet wird. Nur: die Funkschnittstelle ist halt kein KNX, er kann sich also nicht gleich verhalten je nachdem ob er per Funk oder direkt per KNX arbeitet. Im einen Fall hätte er am Bus eine "geteilte" Adresse mit ggf. zig anderen Sensoren, im anderen Fall eine eigene KNX-Adresse. Dadurch das es sich im reine Sende-Module handelt ist es auch nicht so sinnvoll sie als eigene Busteilnehmer abzubilden, denn dann müssten sie auch auf alle Programmiernachrichten etc. reagieren können.
Theoretisch könnte man bei einem Netzversorgten Funkmodul auch die KNX-Kommunikation über Funk durchreichen, aber auch wenn KNX lahm ist, Funk ist nicht schneller und erstrecht nicht zuverlässiger, gerade wo auf dem 433er Band ja alle möglichen Module rumfunken. Und bei 868 müsste man wieder Duty Cycle beachten, die Frequenzen darf man nicht einfach Vollzeit auslasten. Mit Pech ginge dann das Funkmodul nur ein paar Sekunden je Stunde Da müsste man sich dann wohl wirklich mit KNX-RF auseinander setzen.

Also prinzipiell geht ARM, aber praktisch halte ich ihn nicht für nötig und würde keine "Doppelschnittstelle" vorsehen. Wenn eher die Doppelfunktion beim Gateway, dass also der Sensor entweder per Funk kommen kann, oder direkt am Gateway hängt. Einfacher zu löten und leichten zu beziehen ist der AVR auch, auch wenn du noch ein gutes Lager an ARM hast und die AVRs aktuell auch durchaus oft auf ausverkauft stehen und nur als Fertig-Arduino-Modul noch zu bekommen sind.

[Doumanix]

Verstehe, verstehe.
Doppelfunktion am Gateway macht schon Sinn, finde ich. Den Rest kann ich nachvollziehen. Die restlichen Fragen zielten halt darauf ab, ob es auf Dauer nicht übersichtlicher wäre, in einer Familie zu bleiben. Aber wenn's Argumente dafür gibt, warum nicht? So ein funkender Regensensor und / oder Lichtsensor wäre schon nett. Oder eine funkende Wetterstation, wenn auch da das KNX Kabel nicht hin gereicht hat...

[gnampf]

ja, Regensensor wär sicher auch nett, bei mir gings aber erstmal um Bodenfeuchtesensor... also feststellen ob ich mal wieder den Inhalt der Zisterne auf den Rasen verteilen sollte weil der Regen zu lange keine Lust hatte.

Der Code zum Sensoren auswerten sollte sich leicht sowohl auf dem ARM als auch dem AVR compilieren lassen. Im Gateway muß man dann halt die Möglichkeit haben entweder die Funk-Adresse einzustellen, oder den lokalen Anschluß (bzw. I2C-Adresse oder so, je nach Sensor). Der "lustigste" Part bei dem ganzen ist wohl das KNXPROD zu entwerfen und da die ganzen Kombinationen zu bedenken, gerade wo ich per Funk ja auch eine sehr große Anzahl an Sensoren unterstützen würde, die theoretisch von verschiedenen Gateways (parallel) empfangen werden können.

Eine echte KNX-RF-Implementierung wär da sicher schon genial, aber würde ich als deutlich aufwendiger einschätzen, und für batteriebetriebene Sensoren wieder zu stromhungrig.

Ach ja, wenn es dann um sowas wie Taster ginge würde wohl schon ein winziger, billiger ATTIny reichen. Da der auch nicht zyklisch sendet könnte man sowas ggf. sogar mit Knopfzelle betreiben, und das ganze wäre kaum größer als selbige.

[Mirko]

Wenn Du bereits Erfahrung mit dem RFM69 gesammelt hast, bringt das natürlich Sinn, dabei zu bleiben. In Anbetracht der Überbelegung/Duty- Cycle-Thematik des 868MHz Bandes und des Störabstandes beim 433MHz ASK, ist das für viele Sensoren und in die Zukunft gedacht imho nicht so optimal.
Ein SelfBus Zigbee Gateway wäre doch mal was Da gibt es auch viele schöne, günstige Dinge bei Ikea.

Ich mag die AVRs auch sehr gern. Bzgl. Nachbau stört mich aber der notwendige AVR-typische Programmer. Den hat nicht jeder parat. Die AVRs bringen ja leider keinen Bootloader ab Werk mit. Eine kleine Krücke sind dann die Arduinos, da mit Bootloader geliefert. Leider kann man die auch wunderbar "zerflashen", so dass man dann doch wieder einen AVR-Programmer benötigt. Dann vielleicht lieber was aus der SAMD Reihe. Die sind trotz Krise gut verfügbar, haben einen Bootloader und man kann bei der ARM-Toolchain bleiben.
https://www.berrybase.de/neu/seeeduino- ... rtex-m0-43

Von Seeed gibt es da für etwa 10€ auch ein Modul mit SAMD plus LoRA

Auch genial: Der RP2040. Programmer on Board, massig Speicher, StepUp-Wandler (1.8V and 5.5V) auf der Platine und sehr günstig.
https://www.berrybase.de/neu/raspberry- ... ller-board

Bzgl. der AVR/RFM69 Variante lohnt ein Blick auf MySensors (Sicherung der Nachrichten mittels HMAC implementiert!)
https://www.mysensors.org/about/overview

und auf MoteIno
https://lowpowerlab.com/guide/moteino/

[gnampf]

Was 433 angeht: fuer sowas wie Wettersensoren, wo es nicht kritisch ist wann die Nachricht durch kommt, seh ich das unproblematisch. Bei einem Taster sieht das dann ggf. schon anders aus... da ist es nervig wenn der Ding auch nur ein paar 100ms Verzoegerung macht weil jeder irgendein Funkthermometer alles stoert.
Zigbee umgekehrt treibt sich halt im WLAN-2.4GHz-Band rum, was ja auch nicht gerade leer ist. Vorteile sind wohl das sich um Kram wie Duty Cycle & Co sicher da schon der Chipset kuemmert. Aber ob sich Zigbee mit Batteriebetrieb vertraegt?

Stimmt, AVR programmieren ist ja heute nicht mehr so einfach wie frueher, seit ein Parallelport ein Exot ist. Aber wie hast du den Arduino denn zerflasht? Das sollte nicht moeglich sein, sofern derjenige der den Bootloader drauf gepackt hat nicht geschlampt hat. Jaja, ich weiss, die meisten Teile kommen aus China, mit entsprechender Qualitaet... bei korrekt gesetzten Lock-Fuses hat der AVR aber keine Chance den Bootloader-Bereich zu ueberschreiben und startet nach einem Reset auch immer erst im Bootloader.

Ich konzentrier mich erstmal eh aufs Gateway und versuch mal eine Arduino-Kompatibilitaetsschicht einzubauen, damit ich einfach erstmal 1:1 die Arduino-RFM69-Bibliothek einbinden kann. Der Code fuer die bestehenden Sensoren sollte dann recht leicht auf andere Architekturen zu portieren sein, gerade wenn die auch SPI+I2C unterstuetzen oder gar Arduino-kompatibel sind.

Ach ja, Stepup & Co sind im Endeffekt halt auch nochmal zusaetzliche Stromverbraucher. In der jetzigen Kombi laeuft der Kram bis etwa 2V, da sind die AAA-Batterien dann auch wirklich recht ausgelutscht. Klar ginge es mit Stepup ggf. noch etwas tiefer, aber dafuer halt mit Pech mit hoeherem Standbyverbrauch.

Stimmt, mySensors-Kompatibilitaet waere ggf. interessant, da muesste ich mich noch mal mit auseinander setzen.

[Mirko]

Ja, Zigbee kann sehr energiesparend betrieben werden. Ein Schalter läuft mit einer Litium CR-Zelle durchaus einige Jahre. Die 10€ Ikea Dimmer/Schalter laufen bei mir mit einer CR2032 etwa ein bis zwei Jahre. Ein Vorteil von Zigbee ist, dass netzbetriebene Knoten gleichzeitig als Router/Repeater arbeiten können.