Integration von MySensors in FHEM geplant?

[fh168]

Hallo,

ich sehe gerade bei den Attributen:
ich dachte wenn ich autoSubscribeReadings mache, werden alles automatisch erkannt.
Muss man dann mit Subscribe  Reading trotzdem jeden Sensor nochmal einzeln benennen?
Teste ich heute mal nach. Mosquitto habe ich nicht.


Der Blog-Beitrag ist geändert: http://blog.moneybag.de/fhem-sensoren-an-fhem-mit-nrf24l01-transceiver/

Ist mir gerade noch aufgefallen: Wenn ich einen Doppelklick auf subscribeReading_V_TEMP mache, ändert sich nicht die Dropdown-Box, sodass ich einen Wert in das Text-Feld daneben eingeben kann. Man sagt ja hier, man soll nicht in der config rumspielen.

Wie "erkennt" der Broker, das ein Sensor ausgefallen ist, bzw. ob er ein Signal nicht erhalten hat. Ich habe irgendwo gelesen, da man auch Schaltvorgänge (z.b. Relays) damit machen kann MyMQTT/irgendwas/irgendwie ist ja nur ein Kanal, in dem etwas stattfindet.

LG
/robin

[ntruchsess]

die passenden subscribeReading_xxx-attribute werden beim Eintreffen von Nachrichten anhand des Topics automatisch erzeugt. Sobald alle da sind, kann man das autosubscribeReadings wieder rausnehmen. Funktioniert natürlich nur, wenn der Sensor auch Daten schickt.

Was setzt Du für einen mqtt-broker ein?

das Webinterface unterstützt bisher leider keine Wildcard-attribute ('subscribeReading_.*') und da Attribute pro modul-typ und nicht pro Instanz definiert werden, kann man die konkret gesetzten Attribute auch nicht sinnvoll dynmisch zur Liste der editierbaren (instanzspezifischen) Attribute hinzufügen.
Du kannst das aber als kommando 'attr XXX subscribeReading_V_TEMP MyMQTT/21/0/V_TEMP' einfach oben in der Kommandozeile der Weboberfläche absetzen, dann muss Du die fhem.cfg auch nicht von Hand editieren.

Der Broker kann überhaupt nicht erkennen, ob ein Sensor ausgefallen ist, der bekommt einfach keine Nachrichten mehr vom mqtt-gateway. Der Broker kann nur erkennen, wenn das MySensors mqtt-Gateway ausfällt. Prinzipiell könnte eine Sensorüberwachung im mqtt-gateway realisiert werden, aber wenn ich den Code richtig verstehe macht das auch nix anderes als zwischen Funknachrichten und dem mqtt-broker zu mediieren.

Gruß,

Norbert

[fh168]

Werde ich heute abend mal ausprobieren.

ich nutze das MQTT-Gateway von mySensors und Fhem.
Erfährt denn der Broker wenn ein Signal empfangen / nicht empfangen worden ist? Ich denke da so an einer preiswerten Ersatzlösung von HM.

[ntruchsess]

Hm, hab grade mal einen genaueren Blick in die sourcen des mqtt-gateways geworfen. Das implementiert ja gar keinen mqtt-client, sondern eine (unvollständige) mqtt-broker Schnittstelle. Ich halte das nicht wirklich für schlau, weil das mqtt-Protokoll da eben nur teilweise umgesetzt ist, tatsächliche Subscriptions werden nicht unterstützt, qos feht völlig, der verbundene mqtt-client wird daher keine gesendeten Messages freigeben, wenn qos > 0 verwendet wird. Das wird man auch nur bedingt aufbohren können, weil so ein Arduino ja nur sehr geringe System-resourcen hat. Man könnte nun zwar einen mqtt-broker dazwischensetzen (und eine sogenannte Bridge zum mqtt-gateway konfigurieren), das verlagert das Problem aber nur, weil ja auch da (in der Broker<->Gateway Kommunikation) der Broker davon ausgeht mit einem Broker und nicht einem Client zu kommunizieren. Ist mir schleierhaft, warum hier nicht einfach ein MQTT-client implementiert wurde - der würde mit weniger Resourcen trotzdem Spec-konform arbeiten können. Das man sich so einen separaten mqtt-broker spart ist eigentlich kein richtiges Argument. Mosquitto z.B. ist ziemlich schlank, bei mir braucht der Prozess keine 15MB virtuellen und unter 1MB realen Speicher. Und das Einbinden in eine größere Installation (mit zentralem mqtt-broker und anderen über mqtt angebundenen - nicht MySensors - Sensoren und Aktoren) wird so auch zu einem ziemlichen Gebastel.
Ich will da jetzt nicht über ein fremdes Projekt meckern - das ist schließlich Kost-nix Open-Source und jeder darf gerne was dazu beitragen um es zu verbessern und dem Autor des gateways taugt es wohl auch. (Wenn ich mal Zeit und Lust dafür habe, schreibe ich das mal auf einen mqtt-client um)

Für die MySensors-integration in FHEM über mqtt heißt dass aber auch: Alles was nicht geht, weil das mqtt-gateway nicht spec-konform kommuniziert, werde ich FHEM-seitig ignorieren - da kommen keine spezial MySensors-Workarounds rein, das müsste dann auf der mqtt-gateway seite implementiert werden.

Ich schreib dann mal ein FHEM-modul für das serielle MySensors-Gateway, das Protoll ist ja simpel genug. Das Modul wird dann auch gleich mit dem Ethernet-gateway funktionieren.

Stay tuned.

- Norbert

[fh168]

Hallo Norbert,
ich bin ja schon froh, das der Stein ins Rollen gekommen ist. Ich finde die Technik prima, preiswert und einfach.
Das Gateway von mySensors läuft seit mehreren Tagen stabil. Ich kann natürlich jetzt nicht überblicken, was und wie unterstützt ist. Die Sensoren, die dort mit den diversen Sketchen gezeigt werden, funktioneren die meisten (ich hab nicht alle nachgebaut) auch mit fhem.
Wenn es natürlich noch eine einfachere Methode gibt, vielleicht ohne den Arduino Uno (bei mir), sondern direkt am Raspi, ist das natürlich noch besser. Und wenn dann auch noch an dem korrekten Ablauf des MQTT-Protokoll gearbeitet wird, hat man doch für fhem wieder einen zusätzlichen Kommunikationsstandard hinzubekommen.

Serielles / Lan MQTT-Mysensors - Gateway: Klasse, dann kann man sich aussuchen, wie und wo man das Gateway anschließen kann. Daumen hoch!

[ntruchsess]

Für MySensors würde ich immer einen Arduino als Gateway einsetzen, unabhängig davon, ob der nun über USB (seriell) oder Ethernet angebunden ist. Einfach, weil diese Schnittstellen auf praktisch jedem System vorhanden sind (und weil der code für diese Gateways schon existiert). Man könnte zwar grundsätzlch so ein nRF24L01-modul auch direkt über SPI an einem Raspberry Pi anschließen - es ist aber nicht trivial darauf ein portables plattformunabhängiges FHEM-modul aufsetzen zu lassen (das dann auch auf anderen Rechnern läuft), da müsste man erst mal einen Abstraktionslayer für SPI (analog zu den I2C-modulen) dazwischenschieben.

Die Protokoll-implementierung des MQTT-moduls ist aus meiner Sicht vollständig, da kann man sich jetzt eigentlich nur noch Features (wie z.B. das Bridgen von Attribute-werten nach mqtt-topics) dazuwünschen. Für MySensors solltest Du halt darauf achten, dass das Attribut 'qos' auf '0' steht, sonst gibt das Modul den Speicher für ausgehende Messages (MySensors-aktoren) nicht wieder frei.

Gruß,

Norbert

[fh168]

Das meine ich ja.
Arduino.Gateway / über Lan / oder über USB.
Wenn der Benutzer entscheiden könnte, wie er es haben möchte, umso besser.

robin

[hexenmeister]

Habe jetzt die Hardware bekommen und etwas damit rumgespielt.
Die Reichweite ist wirklich überraschend gut. Muss ich etwas genauer testen.
Das Protokoll ist schon recht gesprächig.
Zuerst will der Sensor eine eindeutige ID zugewiesen bekommen, dann ob er metrisch oder imperial messen soll. Wenn er das alles hat, dann kommen Sketch-Name, -Version, vorhandenen Sensoren und eben die Werte.
Ich habe auf die Schnelle aus dem Norberts Modul eine erste Testversion für den Serial-Sketch erstellt. Die grundsätzliche Kommunikation funktioniert, Meldungen werden empfangen und können auch gesendet werden. Ein neuer Sensor bekommt seine ID...
Jetzt fehlt eine Menge Fleißarbeit zum Auswerten von allem möglichen Message- und Sensor-Typen. Vieleicht poste ich morgen eine erste testbare Version...

Code Auswählen Erweitern

2014.10.17 01:00:55.692 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=0,t=17,pt=0,l=3:1.4
2014.10.17 01:00:55.694 3: MySensors: Gateway says: read: 1-1-0 s=255,c=0,t=17,pt=0,l=3:1.4
2014.10.17 01:00:55.696 3: Parse message: 1;255;0;0;17;1.4                                                        <= Protokol 1.4
2014.10.17 01:00:55.699 3: MS_DEV: parse RAW message: MS 1;255;0;0;17;1.4 IODev: mysensors
2014.10.17 01:00:55.701 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:0
2014.10.17 01:00:55.704 3: MySensors: Gateway says: read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:0
2014.10.17 01:00:55.705 3: Parse message: 1;255;3;0;6;0                                                           <= Imperial oder Numeric?
2014.10.17 01:00:57.436 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=11,pt=0,l=8:Humidity
2014.10.17 01:00:57.438 3: MySensors: Gateway says: read: 1-1-0 s=255,c=3,t=11,pt=0,l=8:Humidity
2014.10.17 01:00:57.440 3: Parse message: 1;255;3;0;11;Humidity                                                   <= Sketch: Humidity
2014.10.17 01:00:57.441 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.0
2014.10.17 01:00:57.443 3: MySensors: Gateway says: read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.0
2014.10.17 01:00:57.444 3: Parse message: 1;255;3;0;12;1.0                                                        <= Sketch Verion 1.0
2014.10.17 01:00:57.446 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=0,c=0,t=7,pt=0,l=3:1.4
2014.10.17 01:00:57.447 3: MySensors: Gateway says: read: 1-1-0 s=0,c=0,t=7,pt=0,l=3:1.4
2014.10.17 01:00:57.449 3: Parse message: 1;0;0;0;7;1.4                                                           <= Sensor 0 ist ein Humidity-Sensor
2014.10.17 01:00:57.451 3: MS_DEV: parse RAW message: MS 1;0;0;0;7;1.4 IODev: mysensors
2014.10.17 01:00:57.453 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=1,c=0,t=6,pt=0,l=3:1.4
2014.10.17 01:00:57.454 3: MySensors: Gateway says: read: 1-1-0 s=1,c=0,t=6,pt=0,l=3:1.4
2014.10.17 01:00:57.636 3: Parse message: 1;1;0;0;6;1.4                                                           <= Sensor 1 ist ein Temeratur-Sensor
2014.10.17 01:00:57.637 3: MS_DEV: parse RAW message: MS 1;1;0;0;6;1.4 IODev: mysensors
2014.10.17 01:00:58.681 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=1,c=1,t=0,pt=7,l=5:24.0
2014.10.17 01:00:58.688 3: MySensors: Gateway says: read: 1-1-0 s=1,c=1,t=0,pt=7,l=5:24.0
2014.10.17 01:00:58.689 3: Parse message: 1;1;1;0;0;24.0                                                          <= 24°C
2014.10.17 01:00:58.690 3: MS_DEV: parse RAW message: MS 1;1;1;0;0;24.0 IODev: mysensors
2014.10.17 01:00:58.691 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=0,c=1,t=1,pt=7,l=5:38.0
2014.10.17 01:00:58.692 3: MySensors: Gateway says: read: 1-1-0 s=0,c=1,t=1,pt=7,l=5:38.0
2014.10.17 01:00:58.693 3: Parse message: 1;0;1;0;1;38.0                                                          <= 38 % rH (der DHT11 ist der grösste Schrott)
2014.10.17 01:00:58.695 3: MS_DEV: parse RAW message: MS 1;0;1;0;1;38.0 IODev: mysensors


[ntruchsess]

Hallo Alexander,

ich habe auch schon was geschrieben, aber in Ermangelung von Hardware noch nicht real testen können:

00_MYSENSORS
10_MYSENSORS_DEVICE.pm
lib/Device/Constants.pm
lib/Device/MySensors/Message.pm

(oder einfach den mysensors_unified-branch aus meinem fhem-mirror auschecken:

Code Auswählen Erweitern


git clone https://github.com/ntruchsess/fhem-mirror.git
git checkout mysensors_unified


Da sind schon alle Konstanten für das Protokoll drin, S_GET und S_SET werden auf das (generische) Node-modul umgeleitet. Werte empfangen (S_SET-messages) setzen dynamisch benannte readings, autocreate neuer MYSENSORS_DEVICE-instanzen wenn Presentation-messages eingehen etc... Was noch fehlt ist die Behandlung der ganzen Internal-messages, das ist halt nur im Gateway-sourcecode dokumentiert und selbiges läuft ohne nRF24L01-modul (sollten die Tage mit der Post kommen) nur bis zur ersten Fehlermeldung 'check wires'...

Wäre prima, wenn wir die Aktivitäten bündeln könnten.

Gruß,

Norbert

EDIT 20.10.2014, 19:50 Uhr: Links und Text an den mysensors_unified-branch angepasst

[ntruchsess]

so, die bestellten nRF24L01 sind vorhin gekommen, hab grade das SerialGateway und einen BinarySwitchSensor zusammengestöpselt.

das MYSENSORS-modul redet auch schon brav mit dem Gateway und versteht schon mal die wichtigsten internal-Messages, den Inclusion-mode kann man vom Modul an und abstellen. Allerdings kommt vom Sensor am Gateway nix an (der Sensor loggt nur immer 'req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:' auf seine Serielle Schnittstelle)

(der code im Git ist aktualisiert, urls haben sich dadurch nicht geändert).

Gruß,

Norbert

[hexenmeister]

Hallo Norbert,

der Sensor ist bestimmt in Ordnung, aber bevor er etwas sinnvolles sendet, will er erstmal eine eindeutige ID bekommen.
Das will er mit 'req node id' mitteilen. War bei mir allerdings etwas anders: 255,255,0,3,0 oder so. Das muss dann mit 255,255,0,4,<ID> beantwortet werden.
Das muss der Controller, also FHEM-Modul tun. Danach fragt er noch nach Metric/Imperial (muss aber nicht unbedingt beantwortet werden) und dann kommen Konfig-Daten (presentation etc.) und auch Werte.
Da der Controller sich die ID merkt (EEPROM) ist das beim Testen etwas blöd. Ich überlge schon, mir ein extra Sketch zu bauen, der genau das nicht macht.


Ich habe mir Deinen Code kurz angesehen. Da kann ich wohl noch einiges an Perl lernen. Da Dein Code IMHO schöner ist, werde ich meine Module verwerfen. Ich würde aber gerne da mitarbeiten. Wo könnte ich Dich unterstützen?

Wenn ich beim kurzen Blick richtig verstanden habe, werden Readings wie Konstanten benannt

Code Auswählen Erweitern

use constant variableTypes => qw{ V_TEMP V_HUM V_LIGHT V_DIMMER V_PRESSURE V_FORECAST V_RAIN
        V_RAINRATE V_WIND V_GUST V_DIRECTION V_UV V_WEIGHT V_DISTANCE
        V_IMPEDANCE V_ARMED V_TRIPPED V_WATT V_KWH V_SCENE_ON V_SCENE_OFF
        V_HEATER V_HEATER_SW V_LIGHT_LEVEL V_VAR1 V_VAR2 V_VAR3 V_VAR4 V_VAR5
        V_UP V_DOWN V_STOP V_IR_SEND V_IR_RECEIVE V_FLOW V_VOLUME V_LOCK_STATUS };

sub variableTypeToStr($) {
  (variableTypes)[shift];
}

Finde ich nicht so glücklich. Wollen wir diese auf menschenlesbaren Namen wie 'temperature' mappen? Am besten mit einer Möglichkeit, per Attribut-Definition umzubenennen (für die Custom-Messages)?

Grüße,

Alexander

[hexenmeister]

Architektur-Fragen:

Ich sehe das Modul MYSENSORS als eine Implementierung des Controllers, der alles delegiert und steuert. NODE ist für die Verarbeitung der Nachrichten von und zu einzelnen Nodes Zuständig. Wozu ist dann SENSOR? Sollen alle Readings in einzelnen Module aufgeteilt werden? Ich finde es besser, die Readings einer Node zusammen in einem Device zu fassen.

Die Verarbeitung der Internal-Messages läuft bei Dir im NODE. Wäre das nicht besser im MYSENSORS (also Controller) aufgehoben?

Nutzt Du den Dispatch-Mechanismus gar nicht und rufst einfach entsprechende Methode von den Device-Modulen weiter? Hat das einen bestimmten Zweck?

Möglicherweise sind das doofe Fragen Ich hatte noch nicht die Zeit, den Code ganz genau zu lesen.

Grüße,

Alexander

[ntruchsess]

Hab grade den sensor-sketch auf einen Nano geflasht, schon kommen die Nachrichten beim Gateway an... (War vorher auf einem Mega - irgendwie scheint MySensors wohl nicht mit der unterschiedlichen Pinbelegung des SPI-interfaces beim Mega klarzukommen).

Also:

Die Konstanten heißen so, wie in der MySensors-API weil ich 'Device::MySensors' gegebenenfalls als eigene Library (FHEM-unabhängig) veröffendlichen werde. Die sollen auch nicht zwingend zur Anzeige kommen, das ist eher für's logging, oder wenn man eben noch kein Mapping auf 'lesbare' Readings implementiert hat.

Die Trennung in Node und Sensor-modul mache ich, weil an einem Node auch mehrere gleichartige Sensoren dranhängen können. Das über die Reading-namen zu unterscheiden wie es div. GPIO-module tun halte ich für eher unglücklich, da muss man dann fast zwingend noch einen Readingsproxy dazu konfigurieren, wenn man etwas direkt aus dem GUI-heraus (á la 'on/off') schaltbar machen will.
Das Node-modul verwaltet dann die gemeinsame Config (und meldet z.B. den Batteriestand etc), die Sensor-module enthalten nur die Sensor-spezifischen Readings/Sets.

Das zentrale Mysensors-modul verarbeitet die Internal-messages, die vom Gateway kommen. Internal-messages der Nodes werden vom zentralen Modul an die Node-module weiterdeligiert.

Der Dispatch-mechanismus ist mir irgendwie zu ineffektiv für so eng gekoppelte Module. Da wird ja grundsätzlich alles serialisiert/deserialisiert, auch wenn die kommunizierenden Module in der gleichen FHEM-instanz laufen (was ja eher die Regel, als die Ausnahme ist). Das gehört mal grundlegend dahingehend überarbeitet, dass das serialisieren/deserialisieren transparent (und nur bei remote  Aufrufen) erfolgt) und man richtige Objekte übergeben kann. Ist aber eine andere Baustelle.

Wie du unterstützen könntest? Schau einfach in den Code rein und mach Vorschläge, wo Du meinst was machen zu wollen oder zu können. Mach Dir einfach einen clone des fhem-mirrors auf Github und schick mir pull-requests gegen den 'mysensors'-branch.

Gruß,

Norbert

[hexenmeister]

Verstehe, danke für die Erklärungen.
Ich würde zwar besser finden, wenn die Sensoren alle Readings beisamen haben, ansonsten explodiert die Zahl der 'Geräte', allein DHT-Sensoren liefern immer Feuchte und Temperatur gleichzeitig. aber gut...

Ich werde mir heute später alles genauer ansehen.

LG,

Alexander

[ntruchsess]

so, I_ID_REQUEST/RESPONSE ist implementiert.

Schon schick das Ganze - der BinarySwitchSensor schickt ja unmittelbar bei Zustandsänderung und im FHEM kommt es gefühlt verzögerungsfrei an

Gruß,

Norbert