Integration von MySensors in FHEM geplant?

[fh168]

Ethernet gateway läuft ....

[hexenmeister]

Bastelstunde
Es ist schon fast langweilig. Man steckt es zusammen, schaltet ein und... es funktioniert. Da ich keinen freien Transmitter mehr habe, habe ich beschlossen, meinen Humidity-Sensor zu erweitern. Kurzerhand zwei Sketches gemerged und... DEVICE hat ein neues Reading. Da zahlt sich die universale Aufbau aus.

[hexenmeister]

Anregungen/Wünsche/Kommentare

Warnings sind gefühlt weniger geworden. Bei Reset des Nodes kommen aber noch:

Code Auswählen Erweitern

2014.10.23 23:04:51.245 1: PERL WARNING: Use of uninitialized value $fields[1] in join or string at FHEM/lib/Device/MySensors/Message.pm line 33.
2014.10.23 23:04:51.246 3: stacktrace:
2014.10.23 23:04:51.246 3:     main::__ANON__                      called by FHEM/lib/Device/MySensors/Message.pm (33)
2014.10.23 23:04:51.247 3:     Device::MySensors::Message::createMsg called by ./FHEM/00_MYSENSORS.pm (373)
2014.10.23 23:04:51.247 3:     MYSENSORS::sendMessage              called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.23 23:04:51.248 3:     MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.23 23:04:51.249 3:     MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.23 23:04:51.249 3:     MYSENSORS::onInternalMsg            called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.23 23:04:51.250 3:     MYSENSORS::Read                     called by fhem.pl (2923)
2014.10.23 23:04:51.250 3:     main::CallFn                        called by fhem.pl (598)
2014.10.23 23:04:51.251 1: PERL WARNING: Use of uninitialized value in sprintf at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.23 23:04:51.251 3: stacktrace:
2014.10.23 23:04:51.252 3:     main::__ANON__                      called by FHEM/lib/Device/MySensors/Message.pm (40)
2014.10.23 23:04:51.252 3:     Device::MySensors::Message::dumpMsg called by ./FHEM/00_MYSENSORS.pm (374)
2014.10.23 23:04:51.253 3:     MYSENSORS::sendMessage              called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.23 23:04:51.253 3:     MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.23 23:04:51.254 3:     MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.23 23:04:51.255 3:     MYSENSORS::onInternalMsg            called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.23 23:04:51.255 3:     MYSENSORS::Read                     called by fhem.pl (2923)
2014.10.23 23:04:51.256 3:     main::CallFn                        called by fhem.pl (598)



Es wäre schön, wenn nach dem Remappen die alten Readings gelöscht werden:

Code Auswählen Erweitern

attr node mapReadingType_DISTANCE distance
die alte V_DISTANCE_2 soll weg.
Man könnte distance auch analog temperatur und humidity fest integrieren.

Es wäre hilfreich, wenn man die ID-Vergabe etwas beeinflüssen könnte.
Mir schwebt folgendes vor:
- Min/Max ID per Attribut definieren (damit man mehrere unanhängige Ranges für mehrere IOs definieren kann.)
- einmalig die nächste zu vergebende ID bestimmen: Damit wäre möglich, einem Sensor eine bestimmte ID zu verpassen (die er beim Drücken des Inclusion Knopfes dann auch sicher bekommt). Ich denke hier an ein set-Befehl und eine Anzeige in Internals (oder Readings bzw. Attribute?)

Schreib was, was auch ein DAU versteht

Ich denke, hier ist das Problem nicht die Formulierung, sondern die Funktionalität selbst.
Mein Vorschlag wie schon vorher: die Attribute soll die sichtbaren Readings umbenennen, unanhängig davon, ob das schon intern 'umbenannt' wurde oder nicht. Vielleicht sogar so: wenn die Angabe mit Zahl gemacht wird (temperature1) dann soll nur ein bestimmtes Readings umbnannt werden, wenn ohne (temperature) dann die ganze Gruppe, also alle temperature.*
Dann könnte ich ein verständliches Text dazu schreiben

also anstatt  diesem:

Code Auswählen Erweitern

attr node mapReadingType_TEMP xyz
dieses:

Code Auswählen Erweitern

attr node mapReadingType_temperature xyz


Zur Frage nach der Benennung der Readings:
Von Hintelegen aller bekannten Sketches im Modul halte ich nichts.
Aus meiner Sicht wäre ganz gut, wenn bei der ersten Reading die Nummer entfallen könnte (weil die allermeisten Sensoren keine mehrere gleichartigen Readings haben), die andere gleichartigen werden dann durchnumeriert. Jede Art beginnt mit 1:

Code Auswählen Erweitern

temperature
temperature1
temperature2
humidity
humidity1

Zum eindeutigen und wiederholbaren Erkennen sollten doch die Presentation Meldungen reichen. Jeder Sensor sendet diese beim Start, noch bevor die erste Werte kommen. Man könnte sie alle sammeln, sortieren, zur Namensmapping nutzen. Das dürfte eine sicherre Methode sein.
(Ich könnte zum Testen einen Sensor mit mehreren gleichartigen Dingen basteln.)
Was hälst du davon?


Grüße,

Alexander

[eni]

Hallo Norbert, Hallo Alexander,

Vielen Dank an Euch beiden fuer diese grandiose Arbeit!
Das Modul funktioniert einwandfrei, ich bin total begeistert.

Vorab noch eine Entschuldigung - ist mein erster Beitrag im forum, Bitte um Nachsicht, wenn das Format schrecklich ist/wird.

Ich habe bisher mit einem Node mit mehreren Aktoren (Relais) getestet - funktioniert prima
zur Konfiguration/Implementierung hab noch ein paar Fragen


1) inclusion mode, wird der Node angelegt, das Relay aber nicht
   ... es koennte folgendes in set angelegt/zugefuegt werden

Code Auswählen Erweitern


  "LIGHT_x" => [qw(on off)],
  "DIMMER_x" => "",

   + aktueller Wert des Pins in die Readings ?
   ... bin mir nicht sicher, ob man den abfragen kann

   Frage: Kann man das implementieren?


2) wie sieht das setCommands bei einen V_DIMMER, V_LIGHT_LEVEL,  aus?
   Wunsch:

    fhem:> attr MYSENSOR_1 setCommands dimmer1:DIMMER_1:0
    fhem:> set MYSENSOR_1 dimmer1 50

    Aenderung: 10_NYSENSORS_DEVICE.pm:132
      my ($type,$childId,$mappedValue);
      if (defined @values) {
          my $value = @values ? join " ",@values : "";
          ($type,$childId,$mappedValue) = readingToType($hash,$1,$value);
      }
      else{
         ($type,$childId,$mappedValue) = readingToType($hash,$setcommand->{var},$setcommand->{val});
      }

   Workaround:
   fhem:> attr MYSENSOR_1 setCommands DIMMER_1:DIMMER_1:1
   fhem:> attr MYSENSOR_1 setCommands DIMMER_2:DIMMER_2:1
   fhem:> set MYSENSOR_1 DIMMER_1 50
   fhem:> set MYSENSOR_1 DIMMER_1 80

   Frage: Kann man das implementieren, oder besser den Workaround verwenden?


3) bei den Readings erscheinen unterschiedliche ja nach Inhalt von requestAck:
   wenn requestAck == 1 wird switch_x aktualisier
   wenn requestAck == 0 wird LIGHT_x aktualisier
   evtl. hier %static_mappings
   ---
     LIGHT_1 0 2014-10-24 04:56:50
     LIGHT_2 0 2014-10-24 04:59:27
     switch_1 on 2014-10-24 04:46:14
     switch_2 on 2014-10-24 04:19:35

   Frage: Kann ich das konfigurieren, dass die Readings immer im gleichen Wert
          ankommen, und wenn ja wie?


4) set MYSENSOR_1 LIGHT_1 1
   => FM: Unknown argument LIGHT_1, choose one of clear off1 off2 on1 on2 reboot time
   - sollte aber gehen: siehe 10_MYSENSORS_DEVICE.pm:124
     $command =~ /^(.+_\d+)$/ and do {
   - evtl. moeglich, wenn LIGHT_x automatisch angelegt wird (siehe Pkt.1)

   Workaround:
   fhem:> attr MYSENSOR_1 setCommands LIGHT_1:LIGHT_1:1 LIGHT_2:LIGHT_2:1
   fhem:> attr MYSENSOR_1 setCommands LIGHT_2:LIGHT_2:1
   fhem:> set MYSENSOR_1 LIGHT_1 1
   fhem:> set MYSENSOR_1 LIGHT_1 0
   fhem:> set MYSENSOR_1 LIGHT_2 1
   fhem:> set MYSENSOR_1 LIGHT_2 0

   Frage: Kann man das implementieren, oder besser den Workaround verwenden?


Vielen Vielen Dank nochmals an Euch!! und Viele Gruesse
enrico

[ntruchsess]

zu 1) ich verstehe leider nicht, was Du genau meinst. Ich glaube Du beziehst Dich hier auf eine veraltete Version. Released sind die Dateien 00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm. In letzterer sieht das vordefinierte Mapping so aus:

Code Auswählen Erweitern


my %static_mappings = (
  V_TEMP        => { type => "temperature" },
  V_HUM         => { type => "humidity" },
  V_PRESSURE    => { type => "pressure" },
  V_LIGHT_LEVEL => { type => "brightness" },
  V_LIGHT       => { type => "switch", val => { 0 => 'off', 1 => 'on' }},
);

Da fehlen natürlich noch jede Menge Variablentypen. Was soll den für V_DIMM erscheinen? Einfach nur 'dimm'?

Der Aktuelle Code ist im SVN. Sollte per update rüberkommen. Wenn Du einen eigenen Sketch (mit mehreren Aktoren) verwendest, poste den bitte unbedingt auch. (Das automatische Anlegen basiert auf den Presentation-messages des Nodes, wenn der z.B. nicht alle Sensoren/Aktoren meldet, dann geht's nicht)

2) Das Attribut 'setCommands' kann immer nur einmal pro instanz definiert werden. Das sind Kommandos, die man ohne Angabe eines Wertes abschicken will. Also so was wie 'set Wohnzimmerlicht on'. Man muss alle Kommandos gemeinsam in einem Attribut definieren.

Das was Du vermultlich machen willst sollte etwa so gehen:

Code Auswählen Erweitern


'setReadings_DIMMER_1 0,10,20,30,40,50,60,70,80,90,100'
'setReadings_DIMMER_2 0,10,20,30,40,50,60,70,80,90,100'


3)
das mit dem requestAck klingt nach Bug. Schau ich mir an, würde aber gerne vorher wissen, welche Version Du genau verwendest. Deinen Sketch muss ich dazu auch sehen, weil das Update der Readings bei aktiviertem RequestAck durch den Inhalt der Achnowledge-message des Sensors bestimmt wird.

4) LIGHT_1 heißt in der Released version ohne eigenes mapReadingType-attribut 'switch_1' und kann mit per 'set xxx switch_1 on' bzw. 'set_xxx switch_2 off' ohne weitere Einstellungen geschaltet werden.

Gruß,

Norbert

[thunder1902]

Hallo!

Interessante Sache, das MySensors Thema!

Dazu noch eine Frage: Bei Homematic gibt es ja nach dem Schalten eine Rückmeldung von den Sensoren, ob die Lampe nun erfolgreich eingeschaltet wurde. Ist das bei MySensors genauso?

Wenn ja - dann hab ich genau sowas gesucht! MySensors hat ja wahnsinnig viele Möglichkeiten an Sensoren/Aktoren!!

[ntruchsess]

...Rückmeldung von den Sensoren, ob die Lampe nun erfolgreich eingeschaltet wurde. Ist das bei MySensors genauso?

ja, kann mit dem Attribut 'requestAck' an- bzw. abgestellt werden.

[ntruchsess]

Hallo Alex,

danke für die umfangreiche Rückmeldung.

Warnings sind gefühlt weniger geworden. Bei Reset des Nodes kommen aber noch: (perl-warnings entsorgt...)

Diese Warnings sollten jetzt weg sein.

Mir schwebt folgendes vor:
- Min/Max ID per Attribut definieren (damit man mehrere unanhängige Ranges für mehrere IOs definieren kann.)

+ es gibt ein neues Attribute 'last-sensorid' mit dem man den Range der zu vergebenden Ids nach oben hin begrenzen kann. ('first-sensorid' gab es ja schon).
Die id's werden jetzt der Reihe nach aus dem Konfigurierten Range (Default 20-254) vergeben. Schon belegte IDs werden dabei übersprungen.

Aus meiner Sicht wäre ganz gut, wenn bei der ersten Reading die Nummer entfallen könnte
[...]
Zum eindeutigen und wiederholbaren Erkennen sollten doch die Presentation Meldungen reichen.

Dafür müsste man die Zuordnung Reading-name <-> childId in Attribute(n) speichen, weil man die Presentation-messages nicht nochmal anfordern kann und die childIds nicht einfach <gewünschteReadingNummer>-1 sind. Sonst wäre die Zuordnung beim FHEM-neustart weg.

also etwa so:

Code Auswählen Erweitern


attr mapReading_<name> <childId> <readingType>

attr mapReading_temperature5 25 temperature


Damit wäre allerdings die durch 'mapReadingType_<basename> <type>' von Dir gewünschte einfache Zuordnung für alle Readings eines Typs hinfällig.

Gruß,

Norbert

[eni]

Hallo Norbert,

Vielen Dank fuer die schnelle Antwort!

Zu den verwendeten Versionen:
fhem: fhem-code-6803-trunk (hab ich grad aktualisiert)
MySensors: Standard-Beispiel fuer Relays (mit 2 Relais)
  https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/RelayActuator/RelayActuator.ino

zu 1)
  bei aktiven inclusion-mode ist im logfile folgendes zu sehen

  2014.10.24 08:53:06 5: MYSENSORS Read: Rx: fr=001 ci=255 c=000(C_PRESENTATION) st=018(S_ARDUINO_REPEATER_NODE) ack=0 '1.4
  2014.10.24 08:53:06 5: MYSENSORS Read: Rx: fr=001 ci=003 c=000(C_PRESENTATION) st=000(S_DOOR          ) ack=1 '
  2014.10.24 08:53:08 5: MYSENSORS Read: Rx: fr=001 ci=001 c=000(C_PRESENTATION) st=003(S_LIGHT         ) ack=0 '1.4
  2014.10.24 08:53:08 5: MYSENSORS Read: Rx: fr=001 ci=002 c=000(C_PRESENTATION) st=003(S_LIGHT         ) ack=0 '1.4


  ... im fhem wird folgendes angelegt:
  CFGFN
  DEF      1
  IODev      gateway
  I_SKETCH_NAME    Relay
  I_SKETCH_VERSION 1.0
  NAME       MYSENSOR_1
  NR       31
  STATE       
  TYPE       MYSENSORS_DEVICE
  ack       0
  radioId    1

  ... da kann man die Sensoren/Aktoren nicht sehen, die bekommt man nur raus, wenn man ins logfile schaut.
  Mein Wunsch waere, dass die automatisch unter den Sets auftauchen.
  ... es koennte doch fuer die Aktoren das Kommando aus Punkt 2 automatisch aufgerufen werden.
  z.B.: attr MYSENSOR_1 setReading_switch_1 0,1

  Weiter waere es klasse, wenn man beim inclusion-mode oder per get-Funktion den aktuellen Wert der Aktoren/Sensoren abfragen kann.
  Da man sonst keinen aktuellen Zustand/Wert der Aktoren bekommt, bis man den Wert einmal geaendert hat.
  bin mir nicht sicher, ob das mit den mysensor-protokoll geht
  evtl. so
    NODE_ID, CHILD_ID, TYPE , ACK,   SUB-TYPE, PAYLOAD
       1   ,    1    , C_REQ, [01], S_LIGHT
       1   ,    2    , C_REQ, [01], S_LIGHT
       1   ,    3    , C_REQ, [01], S_DOOR

  wollte das so ausprobieren ...
  fhem:> {MYSENSORS::DEVICE::sendClientMessage($defs{MYSENSOR_1}, childId => 1, cmd => 2, subType => 2)}
  kommt aber nichts vom node zurueck.

2014.10.24 10:42:33 5: Cmd: >{MYSENSORS::DEVICE::sendClientMessage($defs{MYSENSOR_1}, childId => 1, cmd => 2, subType => 2)}<
2014.10.24 10:42:33 5: MYSENSORS send: Rx: fr=001 ci=001 c=002(C_REQ         ) st=002(V_LIGHT         ) ack=0 '
2014.10.24 10:42:33 5: MYSENSORS/RAW: /0;
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;/0;3;0;9;send
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send/: 0-0-1-1 s
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s/=1,c=2,t=2,p
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s=1,c=2,t=2,p/t=0,l=0,st=o
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s=1,c=2,t=2,pt=0,l=0,st=o/k:
2014.10.24 10:42:33 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'send: 0-0-1-1 s=1,c=2,t=2,pt=0,l=0,st=ok:
2014.10.24 10:42:33 5: MYSENSORS gateway gateway: send: 0-0-1-1 s=1,c=2,t=2,pt=0,l=0,st=ok:


zu 2)
  ok, verstanden. funktioniert. Merci!
 
  fhem:> attr MYSENSOR_1 setReading_switch_1 0,1

  dann geht folgendes ...
  fhem:> set MYSENSOR_1 switch_1 0

  .... genau das hab ich gesucht!

zu 3)
  ist auch mit der aktuellen Version (fhem-code-6803-trunk) reproduzierbar.
  wenn man in den sets den falschen Wert hat.
  fhem:> attr MYSENSOR_1 setReading_LIGHT_1 0,1

  mit den richtigen Werten (siehe Pkt.2) tritt das Problem nicht auf.
  fhem:> attr MYSENSOR_1 setReading_switch_1 0,1

zu 4)
  hab ich probiert ...
  fhem:> set MYSENSOR_1 switch_1 on
  funktioniert, wenn man die Aktoren wie unter Punkt 2, von Dir beschrieben anlegt.


Die Punkte 2,3,4 haben funktioniert, mit dem Tipp in Punkt 2.
Vielen Dank fuer die schnelle Hilfe!!
Punkt 1 - waere klasse wenn das automatisch geht.

[ntruchsess]

zu 1) verstanden. Autocreate der passenden Attribute basierend auf den Presentation-messages war eh noch auf meiner ToDo-liste. Das ist aber immer erst der zweite Schritt - erst muss man sich über die Semantik der zu erzeugenden Attribute einig sein, sonst hat man bei jeder Änderung die doppelte Arbeit.

[eni]

Hallo Norbert,

Vielen Dank fuer die schnelle Antwort!
Dann war ich mit dem autocreate wohl etwas zu ungeduldig sorry!
Mit den Tipp von Dir funktioniert ja erst mal alles, dann kan ich noch ein wenig basteln und testen.

Vielen Dank und Viele Gruesse
enrico

[fh168]

Ich habe immer noch das Problem das beim Ethernet-Gateway und auch beim Serial Gateway (2 unterschiedliche Arduinos und Transceiver) nach einiger Zeit keine Daten mehr kommen. ACK habe ich auf 1 gesetzt. Gateway sagt auch connect an. Ich habe 3 unterschiedliche Sensoren hier (Hum, Vtemp und V_Tripped). Es kommt nach einiger Zeit nichts mehr an.

Fehlermeldung im Log (verbose 5), keine ahnung ob das was bringt...

Code Auswählen Erweitern

2014.10.24 20:01:54 1: PERL WARNING: Argument "" isn't numeric in sprintf at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.24 20:01:54 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.24 20:01:56 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.24 20:01:57 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/lib/Device/MySensors/Message.pm line 40.

robin

[hexenmeister]

Wie lange dauert es, bis die Daten nicht mehr kommen?
Wie gesagt, bei mir läuft GateWay seit Tagen ohne Unterbrechung.
Die Sensoren lasse ich nicht durchlaufen, aber zum Testen liefen sie schon vielen Stunden am Stück.

Mittlerweile habe ich hier einen etwas monströsen Aufbau mit DHT11 (Temperatur+Feuchte), BH1750 (Licht) und HC-SR04 (Entfernung).
Sketches lassen sich sehr einfach erweitern. Und es sind immer noch erst 69% Flash und 45% RAM des Mini Pro belegt.
Die Lib für BH1750 ist aber doof (nicht genau genug im unteren Bereich, nach oben arg begrenzt). Ich habe mal eine bessere erstellt: http://s6z.de/cms/index.php/arduino/sensoren/15-umgebungslichtsensor-bh1750
Kann aber ohne Anpassung so nicht verwendet werden (allein weil 2 Bytes für den Wert nicht reichen)

[fh168]

30 minuten ungefähr

auch interessant: er zeigt connected an, obwohl das Netzwerk-kabel schon längst wieder abgezogen ist.
(auch im state)

connection
connected
2014-10-24 21:15:01

erst nach shutdown restart steht im state disconnected

[hexenmeister]

zu Net-Gateway kann ich leider nichts sagen, muss ich mal erst einen aufbauen (habe gerade keine Transmitter mehr).
Aber mit dem Serial Gateway laufen die Sensoren definitiv wesentlich länger als eine halbe Stunde problemlos.
Um das Problem einzugrenzen: hast Du an Deinen Gateway die LEDs angeschlossen, dann kannst Du sehen, ob gerade gesendet/empfangen wird. Wäre interessant festzustellen, ob die Daten empfangen werden und nicht zu FHEM weitergeleitet werden, oder gar nicht erst vom Sensor losgesendet werden. Die Beispielsketches senden übrigens nur, wenn sich der Wert ändert. Zum Testen wäre sinnvoll, diese Einschränkung auszubauen.