Hi,
ich bin neu im Thema Hausautomatisierung und möchte imt einem Metering-Projekt starten um ein Gefühl für die verwendete Technik zu bekommen.
Durch lesen bin ich auf das Thema CUL mit der firmware culfw gestoßen, Meßgeräte aus der Umgebung auszulesen.
Da der CUL per Modus auf ein bestimmtes Protokoll festgelegt wird, ist es aktuell schwierig verschiedene Protokolle zu empfangen.
Ich habe nun die Idee mir ein Python-Skript zu schreiben, das den CUL initialisiert und alle zwei Minuten das Empfangsprotokoll von wmbus->lacross->wmbus->lacrosse... ändert.
So erhoffe ich mir mittels nur einem CUL Sensordaten von verschiedenen Protokollen zu empfangen.
Am Ende sollen die empfangenen daten per pipe an ein weiteres programm gereicht werden (wmbusmeters/rtl_433) um die daten zu dekodieren und per MQTT weiterzugeben.
So bleibt man unabhänig vom verwendeten Tool (FHEM, ioBroker, OpenHAB) solange sie MQTT unterstützen.
Gibt es hierbei Dinge zu beachten wären? Ich weiss dass ich dadurch immer zwei Minuten lang keine Daten von einem der Protokolle empfange. Da ich keine Sekundengenaue Auswertung benötige, ist das für mich vernachlässigbar.
Haltet ihr den Ansatz für Zielführend? Gibt es Probleme, wenn man den CUL automatisiert zu oft das Protokoll ändern lässt? Nicht dass dadurch die Lebenszeit des CUL verkürzt wird.
Vielen Dank für Eure Anregungen.
Vorab mal willkommen im Forum.
Was "Lacrosse" angeht: Sicher, dass das ein CUL (mit CUL-firmware) überhaupt kann? EDIT: geht, wenn man es aktiv eincompiliert
Ansonsten dürfte jede Umschaltung zu einem gewissen Verschleiß des/der EEPROM/s führen.
Nach meinem (möglicherweise unvollständigen) Kenntnisstand fährt man mit Signalduino (auf Maple-Basis auch mit mehreren CC1101) universeller, allerdings wäre ich da nicht sicher, ob der WMBUS kann.
Von FHEM dekodierte Daten kann man auch mit Bordmitteln an MQTT weiterreichen, (als eines von mehreren das) Stichwort (für im Prinzip beliebig viele Sensoren): MQTT_GENERIC_BRIDGE
EDIT: Falls die Auswertung direkt in FHEM erfolgen kann - ein "at" mit einem (FHEM-) "Each" könnte das machen, die Bedenken wg. wearout bleiben natürlich...
defmod a1 at +*00:02 set CULxy rfmode {(Each('a1','WMBUS,Lacrosse'))}
Nimm zum einarbeiten die Hardware nanoCUL(SelbstbauCUL). Die Hardware lässt sich mit der Signalduino-firmware oder culfw-firmware flashen.
Als Signalduino kann man verschleißfrei zwischen Funkprotokollen hin- u. herschalten und unterstützt LaCrosse. Hat aber(bin mir nicht zu 100% sicher) keine wmbus-Unterstützung. Die gibt's per culfw.
Wenn alles klappt, kaufst Du Dir einen weiteren nanoCUL.
Ganz wichtig: wmbus funkt meines Wissens mit 433MHz u. Lacrosse mit 868. Zum Testen lässt sich durchaus auch die Frequenz umschalten. Aber es ist nur eine eher unbefriedigende Krücke, weil der jeweilige Funkchip seine Auslegungsfrequenz hat.
Hi, vielen dank für eure Anregungen.
Ich habe in einer google Group eine Aussagen gefunden, dass die culfw beim reinen Moduswechsel nicht in den EEPROM schreibt. Ich denke dass damit keine Probleme auf EEPROM basis auftauchen. Aber selbst bei einem Wechsel alle 5mins wären das 288 Modiwechsel am Tag was ~100000 intervalle im Jahr ausmacht. Ich denke dass jeder EEPROM 100000 schreibzyklen mitmacht.
Bzgl der Idee FHEM zum Auswerten und weiterleiten als MQTT message: ich würde es gerne vermeiden so ein komplexes system wie FHEM am laufen zu haben, nur die Messages zu parsen. Ist vielleicht nicht der schnellste Weg zu einer funktionierenden Lösung, aber um die Auslastung auf den Raspberry Pi gering zu halten hoffentlich der bessere Weg. Ein tool wie rtl_433 kommt etwas schlanker daher.
Gruß Robert
Zitat von: therobber am 15 Januar 2022, 21:08:24
Ich habe in einer google Group eine Aussagen gefunden, dass die culfw beim reinen Moduswechsel nicht in den EEPROM schreibt. Ich denke dass damit keine Probleme auf EEPROM basis auftauchen. Aber selbst bei einem Wechsel alle 5mins wären das 288 Modiwechsel am Tag was ~100000 intervalle im Jahr ausmacht. Ich denke dass jeder EEPROM 100000 schreibzyklen mitmacht.
Gruß Robert
wie wäre denn dieser Group-Link? Und hast du dein Rotate-Script fertig bekommen.