Schalterstatus über MQTT nicht korrekt

Deutsche Foren Fehler
#1

Hallo,

ich habe mit homegear 0.7.15-1580 das Problem, dass beim Anschalten eines Homematic Switches HM-LC-Sw1-Pl-2 z.B. mit dem Befehl homegear -e rc '$hg->setValue(9, 1,"STATE",1);' der Status des Schalters über MQTT nicht korrekt gesetzt wird. Konkret: der Schalter ist definitiv an, aber über mqtt-spy steht der Status von homegear/1111-2222-1abc/plain/9/1/STATE auf false. Ich sehe beim Schalten ganz kurz im mqtt-spy den Status true und dann direkt wieder false, obwohl der Schalter noch angeschalten ist. Im homegear log sehe ich das auch, dass der Status zweimal “gepublished” wird, einmal mit Status true und direkt danach wieder mit false, siehe Log unten. Ist da was im homegear kaputt oder kann das noch an irgendeiner Einstellung liegen?

02/17/18 19:46:31.030 Info: CLI connection accepted. Client number: 24
02/17/18 19:46:31.030 Listening for incoming commands from client number 24.
02/17/18 19:46:31.030 Script Engine Server: Info: Starting script "/var/lib/homegear/scripts/inline.php" with id 5.
02/17/18 19:46:31.035 Script Engine Server: Info: Client number 0 is calling RPC method: setValue
(Integer) 9
(Integer) 1
(String) STATE
(Integer) 1
02/17/18 19:46:31.035 Module HomeMatic BidCoS: Debug: STATE of peer 9 with serial number MEQ0192069:1 was set to C8.
02/17/18 19:46:31.036 Module HomeMatic BidCoS: COC "My-COC": Info: Sending (My-COC): 0E40A011FDAB0A365C5A0201C80000
02/17/18 19:46:31.036 Debug: Writing: As0E40A011FDAB0A365C5A0201C80000
Ar

02/17/18 19:46:31.236 Module HomeMatic BidCoS: COC "My-COC": Info: Sending (My-COC): 0E40A011FDAB0A365C5A0201C80000
02/17/18 19:46:31.236 Debug: Writing: As0E40A011FDAB0A365C5A0201C80000
Ar

02/17/18 19:46:31.274 Script Engine Server: Info: Client number 0 is calling RPC method: peerExists
(Integer) 52
02/17/18 19:46:31.274 Script Engine Server: Response: 
(Boolean) 1
02/17/18 19:46:31.409 Debug (My-COC): Packet 0E408002365C5AFDAB0A0101C8003F enters raisePacketReceived.
02/17/18 19:46:31.410 Debug (My-COC): Packet 0E408002365C5AFDAB0A0101C8003F is now passed to the EventHandler.
02/17/18 19:46:31.409 HomeMatic BidCoS packet received (My-COC, RSSI: -65 dBm): 0E408002365C5AFDAB0A0101C8003F
02/17/18 19:46:31.410 Module HomeMatic BidCoS: Popping from BidCoSQueue: 1
02/17/18 19:46:31.410 Module HomeMatic BidCoS: Message now at front: Message type: 0x2
02/17/18 19:46:31.410 Module HomeMatic BidCoS: Popping from BidCoSQueue: 1
02/17/18 19:46:31.410 Module HomeMatic BidCoS: Info: Queue 1 is empty and there are no pending queues.
02/17/18 19:46:31.410 MQTT Client: Debug: queueMessage(peerId, channel, keys, values) -> peerId=9, channel=0, keys, values
02/17/18 19:46:31.410 MQTT Client: Debug: queueMessage (message) topic: plain/9/0/RSSI_DEVICE message:-65
02/17/18 19:46:31.410 MQTT Client Info: Publishing topic   homegear/1111-2222-1abc/plain/9/0/RSSI_DEVICE
02/17/18 19:46:31.410 Module HomeMatic BidCoS: Info: STATE on channel 1 of HomeMatic BidCoS peer 9 with serial number MEQ0192069 was set to 0xC8.
02/17/18 19:46:31.410 MQTT Client: Debug: Sending: 3334002D686F6D65676561722F313131312D323232322D316162632F706C61696E2F392F302F525353495F44455649434500102D3635
02/17/18 19:46:31.410 Module HomeMatic BidCoS: Info: WORKING on channel 1 of HomeMatic BidCoS peer 9 with serial number MEQ0192069 was set to 0x00.
02/17/18 19:46:31.411 MQTT Client: Debug: queueMessage(peerId, channel, keys, values) -> peerId=9, channel=1, keys, values
02/17/18 19:46:31.411 MQTT Client: Debug: queueMessage (message) topic: plain/9/1/STATE message:true
02/17/18 19:46:31.411 MQTT Client: Debug: queueMessage (message) topic: plain/9/1/WORKING message:false
02/17/18 19:46:31.411 Debug (My-COC): Packet processing of packet 0E408002365C5AFDAB0A0101C8003F took 2 ms.
02/17/18 19:46:31.411 MQTT Client: Debug: Packet received: 40020010
02/17/18 19:46:31.411 MQTT Client: Debug: Received PUBACK.
02/17/18 19:46:31.411 MQTT Client Info: Publishing topic   homegear/1111-2222-1abc/plain/9/1/STATE
02/17/18 19:46:31.412 MQTT Client: Debug: Sending: 332F0027686F6D65676561722F313131312D323232322D316162632F706C61696E2F392F312F5354415445001174727565
02/17/18 19:46:31.412 MQTT Client: Debug: Packet received: 40020011
02/17/18 19:46:31.412 MQTT Client: Debug: Received PUBACK.
02/17/18 19:46:31.412 MQTT Client Info: Publishing topic   homegear/1111-2222-1abc/plain/9/1/WORKING
02/17/18 19:46:31.412 MQTT Client: Debug: Sending: 33320029686F6D65676561722F313131312D323232322D316162632F706C61696E2F392F312F574F524B494E47001266616C7365
02/17/18 19:46:31.413 MQTT Client: Debug: Packet received: 40020012
02/17/18 19:46:31.413 MQTT Client: Debug: Received PUBACK.
02/17/18 19:46:31.436 MQTT Client: Debug: queueMessage(peerId, channel, keys, values) -> peerId=9, channel=1, keys, values
02/17/18 19:46:31.437 MQTT Client: Debug: queueMessage (message) topic: plain/9/1/STATE message:false
02/17/18 19:46:31.437 Script Engine Server: Response: 
(void)
02/17/18 19:46:31.437 MQTT Client Info: Publishing topic   homegear/1111-2222-1abc/plain/9/1/STATE
02/17/18 19:46:31.437 Module HomeMatic BidCoS: Debug: Deleting queue 1 for BidCoS peer with address 0x365C5A
02/17/18 19:46:31.437 MQTT Client: Debug: Sending: 33300027686F6D65676561722F313131312D323232322D316162632F706C61696E2F392F312F5354415445001366616C7365
02/17/18 19:46:31.438 MQTT Client: Debug: Packet received: 40020013
02/17/18 19:46:31.438 MQTT Client: Debug: Received PUBACK.
02/17/18 19:46:31.439 Info: Script with id 5 finished with exit code 0
02/17/18 19:46:31.443 Info: Connection to CLI client number 24 closed.
Falscher Status bei MQTT
#2

Hey,

habe genau den Zwischenstecker auch hier als Beispiel genommen: https://allgeek.de/2017/07/09/homematic-mit-node-red-ueber-homegear/

Das sollte genau so wie du denkst funktionieren. Mir fällt gerade nichts ein, was du da “einstellen” könntest.

so long,
p

#3

Sehr schöner Artikel übrigens, hat mir sehr geholfen! Im Video unter Conclusion sieht man aber auch bei dir, dass es pro Schaltvorgang zwei STATE messages gibt, beim Umschalten von true auf false erhöht sich der Message counter von 14 auf 16, da sollte doch eine Message reichen. Bei mir ist halt das Problem, dass die zweite Message dann auch noch den falschen Status übermittelt. Scheint ein Problem im Homegear zu sein, muss ich mal als Bug berichten.

#4

Danke :slight_smile:

Hmm… ich habe leider meine Steckdose verliehen, sonst könnte ich es gegentesten. Aber das wäre mir aufgefallen, wenn es das Problem geben würde.

Das GIF verfälscht glaube, weil ich da ja ständig hin und her schalte. Die Steckdose bleibt an, auch über längere Zeit. Der Schalter in node-red-dashboard zeigt ja genau dieses Topic an.

Welche Version von Homegear mit welchem CUL/CC1101 setzt du ein?

#5

Ich nutze homegear 0.7.15-1580 mit nem COC.

Sorry, aber ich glaub das GIF verfälscht da nix: Ich sehe am Schluss 8 Messages bei set/1/1/STATE und 16 Message bei plain/1/1/STATE, da würde ich die gleiche Anzahl erwarten, wenn du immer nur über node-red geschalten hast.

In meinem Log sieht man das genauso, dass es zwei plain/9/1/STATE Messages für einen Schaltvorgang gibt und die zweite mit false anstatt true:

02/17/18 19:46:31.410 Module HomeMatic BidCoS: Info: STATE on channel 1 of HomeMatic BidCoS peer 9 with serial number MEQ0192069 was set to 0xC8.
02/17/18 19:46:31.410 MQTT Client: Debug: Sending: 3334002D686F6D65676561722F313131312D323232322D316162632F706C61696E2F392F302F525353495F44455649434500102D3635
02/17/18 19:46:31.410 Module HomeMatic BidCoS: Info: WORKING on channel 1 of HomeMatic BidCoS peer 9 with serial number MEQ0192069 was set to 0x00.
02/17/18 19:46:31.411 MQTT Client: Debug: queueMessage(peerId, channel, keys, values) -> peerId=9, channel=1, keys, values
02/17/18 19:46:31.411 MQTT Client: Debug: queueMessage (message) topic: plain/9/1/STATE message:true
02/17/18 19:46:31.411 MQTT Client: Debug: queueMessage (message) topic: plain/9/1/WORKING message:false
02/17/18 19:46:31.411 Debug (My-COC): Packet processing of packet 0E408002365C5AFDAB0A0101C8003F took 2 ms.
02/17/18 19:46:31.411 MQTT Client: Debug: Packet received: 40020010
02/17/18 19:46:31.411 MQTT Client: Debug: Received PUBACK.
02/17/18 19:46:31.411 MQTT Client Info: Publishing topic   homegear/1111-2222-1abc/plain/9/1/STATE
02/17/18 19:46:31.412 MQTT Client: Debug: Sending: 332F0027686F6D65676561722F313131312D323232322D316162632F706C61696E2F392F312F5354415445001174727565
02/17/18 19:46:31.412 MQTT Client: Debug: Packet received: 40020011
02/17/18 19:46:31.412 MQTT Client: Debug: Received PUBACK.
02/17/18 19:46:31.412 MQTT Client Info: Publishing topic   homegear/1111-2222-1abc/plain/9/1/WORKING
02/17/18 19:46:31.412 MQTT Client: Debug: Sending: 33320029686F6D65676561722F313131312D323232322D316162632F706C61696E2F392F312F574F524B494E47001266616C7365
02/17/18 19:46:31.413 MQTT Client: Debug: Packet received: 40020012
02/17/18 19:46:31.413 MQTT Client: Debug: Received PUBACK.
02/17/18 19:46:31.436 MQTT Client: Debug: queueMessage(peerId, channel, keys, values) -> peerId=9, channel=1, keys, values
02/17/18 19:46:31.437 MQTT Client: Debug: queueMessage (message) topic: plain/9/1/STATE message:false
02/17/18 19:46:31.437 Script Engine Server: Response: 
(void)
02/17/18 19:46:31.437 MQTT Client Info: Publishing topic   homegear/1111-2222-1abc/plain/9/1/STATE
02/17/18 19:46:31.437 Module HomeMatic BidCoS: Debug: Deleting queue 1 for BidCoS peer with address 0x365C5A

Ich muss da auch nochmal mit anderen Geräten bzw. Homegear Versionen spielen.

#6

Hm… kanns wie gesagt gerade nicht gegentesten. ich bekomme meinen Zwischenstecker die Tage wieder, dann prüfe ich das gerne.

@sathya, was sagst du?

#7

Jetzt hab ich es hinbekommen, dass der Status korrekt angezeigt wird. Wenn ich im setValue statt 1 den Wert true verwende:

homegear -e rc '$hg->setValue(9, 1,"STATE",1);'

homegear -e rc '$hg->setValue(9, 1,"STATE",true);'

dann kommen beim Statuswechsel zwar immer noch zwei Messages, aber beide haben den Wert true und der Status wird über MQTT korrekt dargestellt.

Also, alles gut. Danke!

#8

Hallo @der_dag,

die 1 ging nicht, weil Homegear in der Familie HomeMatic BidCoS für die RPC-Ereignisse noch nicht automatisch falsche Datentypen konvertiert hat. Das habe ich gerade geändert. Im nächsten Nightly geht also auch die 1 an dieser Stelle korrekt. Das erste Ereignis wird generiert, wenn du setValue() aufrufst. Das zweite durch das Antwortpaket vom Gerät. Da es sich um unabhängige Ereignisse handelt, lässt es sich nicht so leicht verhindern.

Viele Grüße

Sathya

1 Like
#9

Hallo Sathya,

danke. Es war echt total klar für mich da 0 und 1 hinzuschicken, zumal der Schalter ja auch entsprechend geschalten hat. Hat ne Weile gedauert, es mal mit true und false zu probieren…

Gruß
der_dag