Integration von MySensors in FHEM geplant?

Begonnen von fh555, 06 September 2014, 00:40:58

Vorheriges Thema - Nächstes Thema

Hauswart

Zitat von: r_knipp am 02 Mai 2016, 21:52:00
Im Modulcode steht:

  S_IR                    => { receives => [V_IR_SEND], sends => [V_IR_RECEIVE] }, # Ir sender/receiver device


Aber ich probiere mal nach deinem Vorschlag aus.

Sorry hatte den Sketch nochmal korrigiert und das IR_RECEIVE vergessen zu korrigieren: https://github.com/Kolbi/Arduino/blob/patch-2/libraries/MySensors/examples/IrSensor/IrSensor.ino

So sollte es von der Senden / Empfangen Logik stimmen.
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

r_knipp

#721
Zitat von: Hauswart am 03 Mai 2016, 09:22:04
Sorry hatte den Sketch nochmal korrigiert und das IR_RECEIVE vergessen zu korrigieren: https://github.com/Kolbi/Arduino/blob/patch-2/libraries/MySensors/examples/IrSensor/IrSensor.ino

So sollte es von der Senden / Empfangen Logik stimmen.
Leider nicht. Wie Joe_re schon angemerkt hatte, muss es andersrum sein.
Ich habs auch ausprobiert und es kommt etwas in FHEM an.
Die Angabe im Modulcode hinter dem Device Typ bezieht sich auf den Sensor.
Zum Beispiel diese Sensoren

S_TEMP                  => { receives => [], sends => [V_TEMP] }, # Temperature sensor
S_HUM                   => { receives => [], sends => [V_HUM] }, # Humidity sensor
S_BARO                  => { receives => [], sends => [V_PRESSURE,V_FORECAST] }, # Barometer sensor (Pressure)
S_WIND                  => { receives => [], sends => [V_WIND,V_GUST] }, # Wind sensor
S_RAIN                  => { receives => [], sends => [V_RAIN,V_RAINRATE] }, # Rain sensor
S_UV                    => { receives => [], sends => [V_UV] }, # UV Sensor
S_WEIGHT                => { receives => [], sends => [V_WEIGHT,V_IMPEDANCE] }, # Weight sensor for scales etc.

senden alle Messwerte an FHEM und empfangen nichts.

Der IR-Sensor empfängt V_IR_SEND und sendet V_IR_RECEIVE.
Er empfängt also vom Gateway einen IR-Code, den er weitersenden (V_IR_SEND) soll, und empfängt (V_IR_RECEIVE) von einer Fernbedienung einen IR-Code, den er ans Gateway weiterleitet.

Es muss also heißen MyMessage msg(CHILD_1, V_IR_RECEIVE);

Beta-User

Zitat von: r_knipp am 02 Mai 2016, 22:31:32
...ein Reading, das sich bei Tastendruck ändert.
Allerdings steht immer nur fffff... oder 0000... drin.

Mangels Hardware (jedenfalls bisher):
Gibt es einen Zusammenhang zwischen dem, was Du in der Konsole siehst und den aktualisierten Readings? Ist das auch so bei den Tasten, die der Sensor dekodieren konnte (von Deiner Scheckkarten-FB) oder eher im Sinne eines "toggle"??
Grundsätzlich gibt es eine Begrenzung der jeweils übertragbaren Datenmenge; wenn also bei einem einzigen Tastendruck mehrere Linien Text erzeugt werden, ist das vermutlich nicht zu realisieren (Aus der API 1.5: The maximum payload size is 25 bytes!). :(

Wenn es so wäre, dass dekodierte Tastendrücke auch übermittelt werden, RAW aber nicht, müßtest Du das konkrete FB-Protokoll der Hardware, die Du nutzen willst im Sensor zur (De-)codierung hinterlegen ::)...

ABER: das wäre vermutlich bei jeder Übertragungstechnik so, wenn es klappt, wärst Du deutlich weiter als zu vermuten war (aber MySensors scheint immer für angenehme Überraschungen gut zu sein).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

r_knipp

Zitat von: joe_re am 03 Mai 2016, 11:16:28
Grundsätzlich gibt es eine Begrenzung der jeweils übertragbaren Datenmenge; wenn also bei einem einzigen Tastendruck mehrere Linien Text erzeugt werden, ist das vermutlich nicht zu realisieren (Aus der API 1.5: The maximum payload size is 25 bytes!). :(
Also ich würde mal ganz stark davon ausgehen, dass das als Hex ankommt.
Wie das, was testweise gesendet werden soll (siehe Sensor-Sketch).

irsend.send(NEC, 0x1EE17887, 32); // Vol up yamaha ysp-900

Vorausgesetzt er kann es dekodieren.

Zitat von: joe_re am 03 Mai 2016, 11:16:28
Gibt es einen Zusammenhang zwischen dem, was Du in der Konsole siehst und den aktualisierten Readings? Ist das auch so bei den Tasten, die der Sensor dekodieren konnte (von Deiner Scheckkarten-FB) oder eher im Sinne eines "toggle"??
Ich werde heute Abend mal ein paar Fernbedienungen durchtesten.

Vielleicht auch mal testweise einen Sender aufbauen mit bekanntem und vom Sensor sicher dekodierbarem Protokoll?

Beta-User

Zitat von: r_knipp am 03 Mai 2016, 11:42:59
Also ich würde mal ganz stark davon ausgehen, dass das als Hex ankommt.
Wie das, was testweise gesendet werden soll (siehe Sensor-Sketch).

irsend.send(NEC, 0x1EE17887, 32); // Vol up yamaha ysp-900


Na ja, es dürfte nicht nur der HEX-Code sein; in der Regel muß auch die Art der Codierung mit übergeben werden (wie hier "NEC", das findet sich auch in anderen IR-Projekten, wo diese Info dann z.B. als Teil des http-Strings oä. mitgegeben wird).
Habe eben noch ein wenig gesucht, auch bei anderen Controllern gibt es diverse Probleme, wenn der FB-Code nicht bekannt ist, vgl. z.B. http://www.domoticz.com/forum/viewtopic.php?f=42&t=10678 und hier http://www.domoticz.com/forum/viewtopic.php?f=42&t=10678.

Werde wohl heute abend auch mal einen Receiver aufbauen und ausprobieren, was mit meinen FB's so klappt (oder auch nicht). Ans Senden würde ich mich allerdings erst mal noch nicht machen, ohne das näher verstanden zu haben. Zum einen könnte man immer noch hergehen und (bekannte) Codes hart mit Anweisungen verbinden (wie jetzt "1" und "alles andere"). Generischer wäre wohl, die komplette Sende-Anweisung aus dem Controller (FHEM) zu verschicken. Dazu muß aber das Dekodieren und Kodieren klappen (add new protocols).

@r_knipp: Möchtest Du Deinen aktuellen Code mal posten (bzw. github?)? (Würde aber eigentlich gerne bei der MySensors-2.0.0-beta-Version bleiben wollen, die ich aktuell schon ohne weitere Problemchen verwende und vom grundsätzlichen Sketchaufbau auch einleuchtender finde).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

r_knipp

Zitat von: joe_re am 03 Mai 2016, 13:08:28
@r_knipp: Möchtest Du Deinen aktuellen Code mal posten (bzw. github?)? (Würde aber eigentlich gerne bei der MySensors-2.0.0-beta-Version bleiben wollen, die ich aktuell schon ohne weitere Problemchen verwende und vom grundsätzlichen Sketchaufbau auch einleuchtender finde).
Mein aktueller Code entspricht dem aus diesem Post: https://forum.fhem.de/index.php/topic,26807.msg446750.html#msg446750
Nur halt IR_SEND und IR_RECEIVE vertauscht, wie du vorgeschlagen hattest.

In der 2.0 Beta ist doch der gleiche IR Sketch drin wie in der 1.5

r_knipp

Sooo, ich habe relativ gute Nachrichten. Der Empfang klappt schon mal.
Hier die Power On Taste von der Fernbedienung meines Yamaha Receivers, den ich später auch damit steuern möchte.

send: 100-100-0-0 s=255,c=3,t=15,pt=2,l=2,sg=0,st=ok:0
send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.5.4
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
read: 0-0-100 s=255,c=3,t=6,pt=0,l=1,sg=0:M
sensor started, id=100, parent=0, distance=1
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=9,sg=0,st=ok:IR Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 100-100-0-0 s=3,c=0,t=20,pt=0,l=0,sg=0,st=ok:
Decoded NEC: Value:BE414DB2 (32 bits)
Raw samples(68): Gap:56762
  Head: m8750  s4550
0:m550 s1700 1:m500 s600 2:m500 s1700 3:m550 s1700
4:m500 s1700 5:m550 s1700 6:m500 s1700 7:m550 s550
8:m550 s550 9:m550 s1700 10:m500 s600 11:m500 s600
12:m550 s550 13:m550 s550 14:m550 s550 15:m550 s1700

16:m500 s600 17:m500 s1700 18:m450 s650 19:m550 s600
20:m450 s1750 21:m550 s1700 22:m500 s600 23:m450 s1750
24:m450 s1800 25:m500 s600 26:m500 s1700 27:m550 s1700
28:m500 s600 29:m450 s650 30:m500 s1700 31:m550 s550

32:m550
Extent=67100
Mark  min:450 max:550
Space min:550 max:1800

send: 100-100-0-0 s=3,c=1,t=33,pt=0,l=8,sg=0,st=ok:be414db2
Decoded NEC: Value:FFFFFFFF (0 bits)
Raw samples(4): Gap:39550
  Head: m8750  s2350
0:m500
Extent=11600
Mark  min:500 max:500
Space min:32767 max:0

send: 100-100-0-0 s=3,c=1,t=33,pt=0,l=8,sg=0,st=ok:ffffffff


Er kann den Code dekodieren und sendet ihn ans Gateway. Dieser empfängt den Code auch korrekt und zeigt ihn im Reading an.
Das müsst ihr mir leider einfach mal so glauben, denn wie man an der seriellen Ausgabe am Ende auch sieht empfängt er auch viel Mist.
Ich konnte leider nicht schnell genug einen Screenshot machen.
Der IR-Empfänger ist sehr sensibel und reagiert auch auf künstliches Licht. Jedenfalls hat die Halogenbeleuchtung in meiner Küche sehr viel falsche Signale erzeugt. Keine Ahnung wie man das unterbinden könnte. Vielleicht nicht erkannte Codes einfach nicht senden?
Im Reading steht dann übrigens in meinem geposteten Fall "be414db2".

Ich fahre morgen Nachmittag übers lange Wochenende weg, daher werde ich leider erst nächste Woche wieder dazu kommen mich intensiv damit zu beschäftigen.


Edi77

#727
Hallo

Ich habe mir mal die Concole angeschaut.
Wenn ich das ESP Gateway startet kommt öfters "Radio init fail"
welches meint er damit WLAN oder mysensors ???

Die Verbindung FHEM NodeMCU sollte gehen, ping geht auch, setze ich im FHEM ihn auf Connect oder disconnect tut sich was in der console.
Aber wie kann ich überprüfen ob die Sensoren gehen??

Habe mir noch einen nano mit einem DS18B20 gebaut, tut sich aber auch nichts.



ESP8266 MySensors Gateway
Connecting to xx
......Connected!
IP: 192.168.x.x
GateWay setup done!
0;0;3;0;9;radio init fail

Soft WDT reset

ctx: cont
sp: 3fff0090 end: 3fff02c0 offset: 01b0

>>>stack>>>
3fff0240:  00000000 00000000 3ffeefc8 4020389d 
3fff0250:  3ffe8794 3ffef0d8 00000000 402014df 
3fff0260:  40202298 00000001 00000000 40201eca 
3fff0270:  3b01a8c0 00ffffff 3ffef1d4 3ffef290 
3fff0280:  3ffe864c 3ffef0d8 3ffef1d4 40202707 
3fff0290:  3ffe8790 3b01a8c0 feefeffe feefeffe 
3fff02a0:  3fffdad0 00000000 3ffef288 40205ef0 
3fff02b0:  feefeffe feefeffe 3ffef2a0 40100718 
<<<stack<<<

ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x0f
csum 0x0f
~ld


ESP8266 MySensors Gateway
Connecting to xx
......Connected!
IP: 192.168.x.x
GateWay setup done!
0;0;3;0;9;gateway started, id=0, parent=0, distance=0
MySensors init done!
Server ready!
Client 0 connected
0;0;3;0;14;Gateway startup complete.
Client 0: 0;0;3;0;2;
0;0;3;0;2;1.5.4


Ich habe auch 2 verschiedene Typen vom NRF24L01+ müssten aber doch beide gehen?

(http://pic.admin4all.com/DSC05250.JPG)

Sorry das ich euch belästigt habe, scheint jetzt zu gehen, falsch verkabelter NRF24L01 :(
Der Sensor wurde vom FHEM gefunden, mal schauen ob es morgen Werte liefert, bin jetzt Hunde müde ...........

Edit 4.5. 10:30 Uhr

Der Air Qulity Sensor ist jetzt im FHEM aber es kommen keine Werte.

define MYSENSOR_1 MYSENSORS_DEVICE 1
attr MYSENSOR_1 IODev MySensorsGateway
attr MYSENSOR_1 mapReading_level 0 level
attr MYSENSOR_1 mapReading_unitprefix 0 unitprefix
attr MYSENSOR_1 mode node
attr MYSENSOR_1 room MySensors
attr MYSENSOR_1 verbose 5
attr MYSENSOR_1 version 1.5.4

Habe mal verbose auf 5 gestellt.


LOG

2016.05.04 10:30:24 3: Opening MySensorsGateway device 192.168.x.x:5003
2016.05.04 10:30:25 3: MySensorsGateway device opened
2016.05.04 10:30:25 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2016.05.04 10:30:25 5: SW: 303b303b333b303b323b0a
2016.05.04 10:30:25 5: MYSENSORS/RAW: /0;0;3;0;14;Gateway startup complete.
0;0;3;0;2;1.5.4

2016.05.04 10:30:25 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=014(I_GATEWAY_READY ) ack=0 'Gateway startup complete.'

2016.05.04 10:30:25 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 '1.5.4'

2016.05.04 10:30:27 3: Logo125 S7_connect: connect to PLC with maxPDUlength=240
2016.05.04 10:30:29 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '1'

2016.05.04 10:30:29 5: SW: 303b303b333b303b353b310a
2016.05.04 10:30:29 5: MYSENSORS/RAW: /0;0;3;0;5;1

2016.05.04 10:30:29 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0

2016.05.04 10:31:29 5: MYSENSORS/RAW: /0;0;3;0;5;0

2016.05.04 10:31:29 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '0'

2016.05.04 10:31:29 5: MYSENSORS send: Rx: fr=000 ci=000 c=-01(''            ) st=005(''              ) ack=0 '1'

2016.05.04 10:31:29 5: SW: 303b303b2d313b303b353b310a


fr, ci und c sollten dann die Werte sein.
Wie bekomme ich die am besten in eine Log file ?

Vielleicht kann mir noch jemand sagen wie man am besten die fake NRF24L01+ von den echten unterscheiden kann?
Oder wo ihr die NRF24L01+ bezieht die gut laufen?
Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

r_knipp

Zitat von: r_knipp am 03 Mai 2016, 23:02:26
Der IR-Empfänger ist sehr sensibel und reagiert auch auf künstliches Licht. Jedenfalls hat die Halogenbeleuchtung in meiner Küche sehr viel falsche Signale erzeugt. Keine Ahnung wie man das unterbinden könnte. Vielleicht nicht erkannte Codes einfach nicht senden?


void loop() 
{
gw.process();
  if (irrecv.GetResults(&decoder)) {
    irrecv.resume(); 
    decoder.decode();
    decoder.DumpResults();
         
    char buffer[10];
    sprintf(buffer, "%08lx", decoder.value);
    // Send ir result to gw
    gw.send(msg.set(buffer));
  }
}


Die Funktion decode() gibt anscheinend true oder false zurück.
Aus IRLib.cpp:

bool IRdecode::decode(void) {
  if (IRdecodeNEC::decode()) return true;
  if (IRdecodeSony::decode()) return true;
  if (IRdecodeRC5::decode()) return true;
  if (IRdecodeRC6::decode()) return true;
  if (IRdecodePanasonic_Old::decode()) return true;
  if (IRdecodeNECx::decode()) return true;
  if (IRdecodeJVC::decode()) return true;
//if (IRdecodeADDITIONAL::decode()) return true;//add additional protocols here
//Deliberately did not add hash code decoding. If you get decode_type==UNKNOWN and
// you want to know a hash code you can call IRhash::decode() yourself.
// BTW This is another reason we separated IRrecv from IRdecode.
  return false;
}


Das müsste man doch einfach abfragen können und nur bei true gw.send(msg.set(buffer)) ausführen.

Beta-User

Zitat von: r_knipp am 04 Mai 2016, 10:45:07

Das müsste man doch einfach abfragen können und nur bei true gw.send(msg.set(buffer)) ausführen.

Das wäre ein Lösungsansatz; evtl. könnte es auch helfen, einen Widerstand einzubauen (bzw. die Empfängerschaltung etwas aufzubohren). Was hast Du denn für einen Empfänger? Ein ganzes Modul wie auf der MySensors-Seite oder (wie ich) einen einzelnen Empfänger?

Für meinen (VS1838B)  sähe das so aus wie im Anhang: 100 Ohm an VCC, 20 kOhm Pullup (OUT/VCC). Irgendwo fand ich auch den Hinweis, zwischen 100 Ohm und 330 Ohm zwischen OUT und Arduino-Pin zu hängen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Edi77

Nur mal so eine Idee

Es gibt von MySensors auch den Door/window/Button.
So wie ich das sehen gibt es das FHT80b / FHT80TF-2 nicht mehr.

Wäre es eine Lösung den MySensors Door/window/Button auszuwerten und wenn das Fenster/Tür offen/geschlossen über die FHEM CUL einen FHT80TF-2 für einen FHT80B zu emulieren? sprich das der FHEM dann ein FHT80TF-2 Signal sendet?  ::)
Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

r_knipp

Zitat von: Edi77 am 04 Mai 2016, 11:25:15
Nur mal so eine Idee

Es gibt von MySensors auch den Door/window/Button.
So wie ich das sehen gibt es das FHT80b / FHT80TF-2 nicht mehr.

Wäre es eine Lösung den MySensors Door/window/Button auszuwerten und wenn das Fenster/Tür offen/geschlossen über die FHEM CUL einen FHT80TF-2 für einen FHT80B zu emulieren? sprich das der FHEM dann ein FHT80TF-2 Signal sendet?  ::)
Warum denn etwas emulieren? Weiß auch gar nicht wie das gehen sollte. Eines der beiden Geräte hat doch bestimmt ein Reading für Fenster offen/geschlossen.
Das Signal würde er doch sonst vom Fensterkontakt bekommen. Das sollte man doch dann in FHEM setzen können.

Beta-User

#732
Zitat von: Edi77 am 04 Mai 2016, 11:25:15
Nur mal so eine Idee

Es gibt von MySensors auch den Door/window/Button.
So wie ich das sehen gibt es das FHT80b / FHT80TF-2 nicht mehr.

Wäre es eine Lösung den MySensors Door/window/Button auszuwerten und wenn das Fenster/Tür offen/geschlossen über die FHEM CUL einen FHT80TF-2 für einen FHT80B zu emulieren? sprich das der FHEM dann ein FHT80TF-2 Signal sendet?  ::)

Sollte eigentlich kein Problem sein: http://www.fhemwiki.de/wiki/CUL_FHTTK und ein NOTIFY/IF/DOIF sollten diesen Job erledigen können.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

r_knipp

Zitat von: joe_re am 04 Mai 2016, 11:12:25
Was hast Du denn für einen Empfänger? Ein ganzes Modul wie auf der MySensors-Seite oder (wie ich) einen einzelnen Empfänger?
Ich habe die bei MySensors empfohlene Sender/Empfänger-Kombi. War am einfachsten anzuschließen.
Ich habe aber auch noch TSOP1738 rumliegen. Könnte ich auch mal ausprobieren. Aber leider erst nächste Woche.

r_knipp

#734
Zitat von: joe_re am 04 Mai 2016, 11:44:03
Sollte eigentlich kein Problem sein: http://www.fhemwiki.de/wiki/CUL_FHTTK und ein NOTIFY/IF/DOIF sollten diesen Job erledigen können.
Kannte ich noch gar nicht. Dann sollte das doch gehen.

Aber was ist denn mit diesem: http://www.elv.de/homematic-hm-sec-sc-funk-tuer-fensterkontakt-1.html
Ok... etwas teurer als ein MS-Sensor...