Integration von MySensors in FHEM geplant?

[Edi77]

Hallo,

Die Version 2.1.0 ist jetzt Release und was ich auch entdeckt es werden jetzt nicht nur die NRF24L01+ unterstützt sondern auch die RFM69HW (868MHz), wo schon Reichweiten bis 5,8km bei freier Sicht erzielt wurden.

Mich würde hier mal interessieren was ihr so im Outdoor Bereich an Reichweiten erzielt habt besonders ohne Sichtverbindung und mit welchem System?

[gloob]

Ich habe mir jetzt auch mal ein paar RFM69HW für das Gateway und RFM69W Module für die Sensoren bestellt.
Ich bin auf die Reichweite gespannt und werde berichten.

[tonyf]

hallo zusammen,

bis gestern hatte ich mySensors 2.0.0 im Einsatz, testweise mit einem Relay Aktuator, mit Standard Sketches aus mysensors.org ohne Änderungen (nur IP und NODE-ID)
Es hat auch alles tadellos funktioniert.

Meine Config:

Code Auswählen Erweitern


define MySensorGateway MYSENSORS 192.168.178.166:5003
attr MySensorGateway autocreate 1
attr MySensorGateway first-sensorid 1
attr MySensorGateway fp_COCKPIT 63,1349,1,mysensors gateway,
attr MySensorGateway requestAck 1
attr MySensorGateway room mySensors
attr MySensorGateway stateFormat connection

define MYSENSOR_3 MYSENSORS_DEVICE 3
attr MYSENSOR_3 IODev MySensorGateway
attr MYSENSOR_3 mapReading_power1 1 power
attr MYSENSOR_3 mapReading_status1 1 status
attr MYSENSOR_3 requestAck 1
attr MYSENSOR_3 room mySensors
attr MYSENSOR_3 setCommands on:status1:on off:status1:off
attr MYSENSOR_3 setReading_power1 1
attr MYSENSOR_3 setReading_status1 on,off
attr MYSENSOR_3 stateFormat status1


Jetzt nach dem Update auf 2.1.0:
- Im seriellen Monitor ist das Gateway fehlerfrei, Sensor kann man hardwaremässig triggern und meldet erfolg und bekommt Acknowledge vom Gateway
- autocreate funktioniert nicht mehr
- manuelles Schalten des Sensors im FHEM (s.Bild)  führt nur dazu, dass das Gateway verschwindet/auftaucht, Sensor bewegt sich nicht:

2017.01.04 14:43:22 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:22 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.04 14:43:23 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:23 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.04 14:43:26 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:26 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.04 14:43:28 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:28 1: 192.168.178.166:5003 reappeared (MySensorGateway)

eine Idee ?

Danke&Gruss
Tony

[hjgode]

Hallo tonyf

ich würde so vorgehen:

Gateway wieder auf 2.0.0 zurückflashen, wenn sonst nix geändert wurde müsste Dein Actor wieder funktionieren

Geht trotzdem nicht? Dann mal fhem beenden (oder das MySensors Gateway Devive de-aktivieren) und mit dem MSysController testen, läuft mit Netzwerk-Gateway, wie bei Dir, auch unter Linux (mit wine).

Wenn das auch nicht geht, hat sich vielleicht die IP des Gateways geändert? Der MySensors Netzwerk Gateway Sketch offeriert eine einfache Telnet-ähnliche Netzwerkschnittstelle unter IP und Port 5003. Die kann man auch mit telnet oder puTTY öffnen:

Code Auswählen Erweitern

telnet 192.168.0.118 5003
0;0;3;0;2;
0;255;3;0;2;2.0.1-beta

Die Eingabe 0;0;3;0;2; ist der Code zur Abfrage der Versionsnummer. Auf meinem Netzwerkgateway läuft derzeit 2.0.1-beta, wie man aus der Antwort des Gateways erkennen kann: 0;255;3;0;2;2.0.1-beta

Wenn Du noch nicht mal mit Telnet oder puTTY was mit dem Gateway anfangen kannst, dann funktioniert entweder der Sketch oder Dein Netzwerk nicht wie gewünscht.

Wenn der FHEM MySensors Gateway Code gestartet wird, baut er eine Netzwerkverbindung zum Port 5003 auf und sendet die Versionsabfrage an das MySensors Gateway. Danach lauscht der FHEM Code nur auf MySensors Sensoren Nachrichten oder gibt Actor Nachrichten an das MySensors Netzwerk weiter. Kann man ähnlich (aber schöner) im MSysController sehen und testen.

Bin gespannt, was bei Dir als Fehlerursache rauskommt.

~josef

[hjgode]

 @hauswart oder ?

Folgendes Problem:
Man hat ein MySensors Netzwerk-Gateway und ausschließlich Batterie-optimierte Sensoren. Die Sensoren senden nur ganz selten Updates zum Gateway.
FHEM wird mit MySensors Definitionen gestartet, der Gateway antwortet brav auf die Versionsbfrage und dann passiert eigentlich nichts mehr ausser, ein Sensor sendet eine Nachricht an das Gateway. Man weiss nicht, ob der Gateway noch mit FHEM verbunden ist, es sei denn man vermisst die Sensor-Updates.

Mein (erster) Sensor sendet beim Einschalten und dann alle 5 Minuten ein Update. In meinem Fall war des öfteren der Gateway nicht mehr mit FHEM verbunden. Dies stellte ich fest, nachdem ich MSysController auf das selbe Gateway verbunden hatte und dort die Sensor-Updates angezeigt wurden, aber in FHEM nicht.
Ich habe habe dann in FHEM ein set Disconnect und dann set Connect machen müssen, damit die Sensorupdates auch in FHEM ankommen.

Das Problem ist, dass normalerweise keine Kommunikation zwischen FHEM und Gateway stattfindet. Der FHEM keep_alive Timeout für das erste keep_alive Paket wird systembedingt erst nach 2 Stunden! gesendet, dann alle 75 Sekunden (könnte man in DevIO.pm mit Socketoptionen für FHEM anpassen). Also würde mann eventuell erst nach fast zwei Stunden feststellen, das der Gateway nicht mehr mit FHEM verbunden ist.

Das ist leider bei MySensors im Bezug auf das Netzwerk-Gateway nicht beachtet worden.

Abhilfe könnte man zB durch eine periodische Abfrage der Gateway Versionsnummer aus FHEM heraus schaffen. Dazu müsste aber der 00_MySensors code angepasst werden. Wiederholung meiner vorgeschlagenen Änderung:

Code Auswählen Erweitern

--- 00_MYSENSORS.pm.org 2017-01-04 19:26:36.437086228 +0100
+++ 00_MYSENSORS.pm 2017-01-04 07:44:12.811919078 +0100
@@ -19,7 +19,7 @@
#     You should have received a copy of the GNU General Public License
#     along with fhem.  If not, see <http://www.gnu.org/licenses/>.
#
-# $Id$
+# $Id: 00_MYSENSORS.pm 9341 2015-10-02 14:55:54Z ntruchsess $
#
##############################################

@@ -218,6 +218,19 @@
   return undef;
}

+# GetConnectStatus
+sub GetConnectStatus($){
+ my ($hash) = @_;
+ my $name = $hash->{NAME};
+ Log3 $name, 4, "MySensors: GetConnectStatus called ...";
+   
+ #query version from gateway
+    sendMessage($hash, radioId => 0, childId => 0, cmd => C_INTERNAL, ack => 0, subType => I_VERSION, payload => '');
+
+ # neuen Timer starten in einem konfigurierten Interval.
+ InternalTimer(gettimeofday()+300, "MYSENSORS::GetConnectStatus", $hash);
+}
+
sub Timer($) {
   my $hash = shift;
   my $now = time;
@@ -247,6 +260,8 @@
   Log3 ($name, 5, "MYSENSORS/RAW: $data/$buf");
   $data .= $buf;

+  readingsSingleUpdate($hash,"lastRead","$buf",1);
+
   while ($data =~ m/\n/) {
my $txt;
($txt,$data) = split("\n", $data, 2);
@@ -348,6 +363,8 @@
   my $client = shift;
   MYSENSORS::DEVICE::onGatewayStarted($client);
});
+ #start connect watch thread, interval 500
+ InternalTimer(gettimeofday()+300, "MYSENSORS::GetConnectStatus", $hash);
last;
   };
   $type == I_VERSION and do {


Damit wird zum einen jede empfangene Nachricht als lastRead (mit Zeitstempel) in FHEM angezeigt und mann eine Watchdog draufsetzen. Und zum anderen sendet der Code alle 5 Minuten eine Versionsabfrage an das Gateway.

Das Gateway gibt ja noch nicht mal ein OK zurück, wenn man was schickt. Entweder kommt einen Antwort oder eben nix.

Man könnte auch den Gateway Sketch ändern, und alle paar Minuten etwas zum Host schicken. Dann müsste aber auch 00_MySensors angepasst werden.

Bei einem seriell angebunden Gateway kommt die Netzwerk-Problemmatik nicht zum tragen. Wenn man den Gateway 'abzieht' bekommt FHEM das sofort mit, Ist halt ne Hardware-Verbindung. Ob der Gateway aber noch 'lebt', weill vielleicht der Sketch spinnt, weiss man bei dem seriellen Gateway auch nicht ohne periodische Abfrage.

Bei mir läuft sowohl die DevIO socket Änderung als auch o.g. periodische Abfrage. So weiss ich mit ziemlicher Sicherheit, ob mein Gateway noch lebt.

~Josef

[gloob]

Ich finde die Änderungen sehr gut, die du gemacht hast und hoffe, dass sie übernommen werden.

Ansonsten könnte man wie von dir vorgeschlagen auch den Gateway Sketch abändern und einen "lokalen Sensor" am Gateway simulieren. Ich dachte hier an einen einfachen Counter welcher alle 5 Minuten inkrementiert wird. Der Counter wird in FHEM wie ein normaler Node angelegt und hierüber könnte man auch einen Watchdog triggern.

[Hauswart]

Ich war leider arbeitsbedingt die letzten Wochen wieder stark eingespannt und habe auch zwischen Weihnachten und Neujahr leider keine Zeit gefunden. Heute Nachmittag sollte ich jedoch ein paar Minuten finden und mal die längst gemachten Änderungen an Norbert senden, damit diese in offizielle Release kommen.

Deine Änderung schaue ich mir auch gleich mal an.




Edit: Ich habe hjgode's Patch mal hier eingebaut: https://raw.githubusercontent.com/Kolbi/fhem-mirror/Kolbi-patch-2/fhem/FHEM/00_MYSENSORS.pm bitte testen




Der Gateway Lösch Patch und der Windows Fix sind bereits als Pull Request bei Norbert. Die Library Anpassungen noch nicht, die möchte ich selbst eigentlich vorher mal testen.






*kaffee*

[Beta-User]

die längst gemachten Änderungen an Norbert senden, damit diese in offizielle Release kommen.

@Hauswart,

zur Info: habe den Stand von ca. Ende Nov. seit Installation ohne erkennbare Probleme im Einsatz (serielles GW mit 2.1 bzw. 2.1-beta), seither allerdings auch kein neuen Sensoren mehr aufgebaut.

@tonyf:
Ist das ein WIFI-GW oder ein Ethernet-GW?
Jedenfalls bei den Arduino-Varianten unter Verwendung der Arduino-IDE ist evtl. ein Downgrade der Board-Definitionen (<=1.6.11) ein Weg, um dauernde Reboots zu verhindern (das scheint auch bei der IDE 1.8 noch nicht behoben zu sein, habe es aber nicht ausgiebig getestet); bei den Reboots gehen auch Daten verloren.
Es gibt auch für die Sensbender-ESP's eigene Board-Definitionen; ob die dasselbe Thema addressieren, weiß ich allerdings nicht. Hast Du diese ggf. verwendet?

[Hauswart]

@Hauswart,

zur Info: habe den Stand von ca. Ende Nov. seit Installation ohne erkennbare Probleme im Einsatz (serielles GW mit 2.1 bzw. 2.1-beta), seither allerdings auch kein neuen Sensoren mehr aufgebaut.

Dann werde ich diesen Teil heute auch via Pull Request an Norbert senden.

[tonyf]

Guten morgen zusammen,

danke für die antworten.
Es handelt sich un Ethernet Gateway mit Arduino Nano und mySensors V 2.1.0 volle Version, welche vor kurzen freigegeben wurde, also kein Beta.
Das Problem mit den Board-Definitionen und IDE ist mir bekannt. 2.0.0 habe ich mit IDE 1.6.9 eingesielt und hat sehr gut funktioniert.
Jetzt verwende ich IDE 1.8.0, 2.0.0 macht natürlich Probleme - das ist bekannt -, komischerweise ist das nicht der Fall bei 2.1.0. Es lässt sich wunderbar einspielen ohne das ständige Gateway Reboot.

@hjgode: telnet 192.168.168.166 5003 funktioniert, die Abfrage liefert aber kein Ergebnis

Gateway und Aktor funktioneren ausserhalb FHEM problemlos.

das Gateway, sauberer Start ohne Reboots:

0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGA--,VER=2.1.0
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
IP: 192.168.178.166
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1

Der Relay-Aktor mit Button:

0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.0
3 TSM:INIT
4 TSF:WUR:MS=0
11 TSM:INIT:TSP OK
13 TSF:SID:OK,ID=3
15 TSM:FPAR
51 TSF:MSG:SEND,3-3-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2058 !TSM:FPAR:NO REPLY
2060 TSM:FPAR
2096 TSF:MSG:SEND,3-3-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2375 TSF:MSG:READ,0-0-3,s=255,c=3,t=8,pt=1,l=1,sg=0:0
2380 TSF:MSG:FPAR OK,ID=0,D=1
4104 TSM:FPAR:OK
4105 TSM:ID
4106 TSM:ID:OK
4108 TSM:UPL
4111 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
4120 TSF:MSG:READ,0-0-3,s=255,c=3,t=25,pt=1,l=1,sg=0:1
4125 TSF:MSG:PONG RECV,HP=1
4128 TSM:UPL:OK
4129 TSM:READY:ID=3,PAR=0,DIS=1
4134 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
4141 TSF:MSG:READ,0-0-3,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
4148 TSF:MSG:SEND,3-3-0-0,s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=OK:2.1.0
4156 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
6164 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=11,pt=0,l=14,sg=0,ft=0,st=OK:Relay & Button
6173 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
6192 TSF:MSG:SEND,3-3-0-0,s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
6198 MCO:REG:REQ
6201 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
8208 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
8214 TSF:MSG:READ,0-0-3,s=255,c=3,t=27,pt=1,l=1,sg=0:1
8219 MCO:PIM:NODE REG=1
8222 MCO:BGN:STP
8223 MCO:BGN:INIT OK,TSP=1
16793 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:1
16802 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:1
16806 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 1
22012 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:0
22022 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:0
22026 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 0
26494 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:1
26504 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:1
26508 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 1
30884 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:0
30894 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:0
30898 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 0

Man sieht, ich kann umschalten ohne Probleme und Relay klackert anständig.

Mit FHEM will es einfach nicht, keine Reaktion ausser Schwankung des Gateways.

Gruss
Tony

[hjgode]

Mit FHEM will es einfach nicht, keine Reaktion ausser Schwankung des Gateways.

Dann würde ich ein Backup der fhem.cfg machen, FHEM beenden, dann alles zu MySensors aus der fhem.cfg entfernen und dann FHEM neu starten. Anschliessend den Gateway neu anlegen und sehen, ob er sich dann normal benimmt. Falls das auch nicht geht, die FHEM Module (pm Dateien) zu MySensors prüfen. Nicht dass in den Dateien was kaputt ist.

~josef

[Hauswart]

Dann würde ich ein Backup der fhem.cfg machen, FHEM beenden, dann alles zu MySensors aus der fhem.cfg entfernen und dann FHEM neu starten. Anschliessend den Gateway neu anlegen und sehen, ob er sich dann normal benimmt. Falls das auch nicht geht, die FHEM Module (pm Dateien) zu MySensors prüfen. Nicht dass in den Dateien was kaputt ist.

~josef

Verwendest du die ganz normalen Stable Dateien? Oder meine Dev?


Hast du mir den Sketch (oder Link) zum Sensor?

[tonyf]

Danke ..
das hat nichts gebracht,

FHEM ist aktuell, mySensors Modul ist der stable.

Gateway: https://www.mysensors.org/build/ethernet_gateway -> Änderung nur die IP  nach 192.168.178.166
Relay mit Button: https://www.mysensors.org/build/relay -> Änderung nur eingefügt  MY_NODE_ID 3

Gruss
Tony

[PeMue]

Hallo zusammen,

Jedenfalls bei den Arduino-Varianten unter Verwendung der Arduino-IDE ist evtl. ein Downgrade der Board-Definitionen (<=1.6.11) ein Weg, um dauernde Reboots zu verhindern (das scheint auch bei der IDE 1.8 noch nicht behoben zu sein, habe es aber nicht ausgiebig getestet); bei den Reboots gehen auch Daten verloren.

irgendwie kompiliert die Arduino IDE nicht mehr mit der Board Definition 1.6.16. Da kommt folgender Fehler beim Blink Sketch:

Code Auswählen Erweitern

cc1.exe: error: -fno-fat-lto-objects are supported only with linker plugin.
Error compiling.
(Windows XP bzw. Windows 7, Board Definition s.o.).

Wo seht ihr, dass die Board Definition einen Fehler hat? Welche Board Definition sollte man verwenden?
Der ganze Spaß hat mich jetzt knapp 3 Tage gekostet 

Danke + Gruß

PeMue

[hjgode]

Danke ..
das hat nichts gebracht,

FHEM ist aktuell, mySensors Modul ist der stable.

Gateway: https://www.mysensors.org/build/ethernet_gateway -> Änderung nur die IP  nach 192.168.178.166
Relay mit Button: https://www.mysensors.org/build/relay -> Änderung nur eingefügt  MY_NODE_ID 3

Gruss
Tony

Möglicherweise liegt es an der IP? Ich habe zuerst auch eine statische IP versucht (MySensors 2.0.1-beta), ging irgendwie nicht. Deshalb läuft der Sensor bei mir mit DHCP und einer reservierten IP.