mysteriöses Verhalten zwischen goupids

[arm9999]

Hallo,
seit ein paar Wochen (evtl. seit dem letzten update) habe ich ein seltsames neues Verhalten von FHEM beim Ändern von Werten innerhalb einer groupid. Dabei wird zum Beispiel setdesiredTemperature bei einem WT nach etwa 2-3 Minuten zusätzlich auf nur einer andere groupid angewendet. Im LOG kann ich aber keinen entsprechenden Befehl erkennen der das auslöst? Mysteriös dabei ist, dass eine manuelle Verstellung innerhalb einer Gruppe dieses Verhalten nicht auslöst, sondern nur bei Änderungen über FHEM. Auch das immer nur eine bestimmte Gruppe eine andere beeinflusst, so als ob noch ein Befehl in sendqueue wäre, der aber mit einer anderen groupid nochmals verknüpft wird. Im code habe ich noch nicht nachgeschaut, abr werden hier vlt. irgendwelche Bit maskiert oder links/rechts verschoben und im Carry Bit ist aber noch etwas von vorher drinnen?

mein setup:
10 HTs und 4 WTs aufgeteilt in 6 gruppen (groupid 1-6)
die HTs einer Gruppe sind an den zugehörigen WT assoziert (und vice versa der WT an alle HTs seiner Gruppe)
gateway ist ein mit a-culfw umgeflashter MaxCube (CUBEe)
alle HT und WT wurden schon resettet und neu mit dem CUL gepaairt, passt auch alles und funktioniert top, bis auf dieses neue Verhalten
Reihenfolge in der fhem.cfg schon geprüft und verändert, ohne Ergebnis

Effekt:
Gruppe 1 -> Gruppe 2
Gruppe 2 -> Gruppe 3
Gruppe 3 -> Gruppe 5
Gruppe 4 -> ------
Gruppe 5 -> ------
Gruppe 6 -> Gruppe 1

Mir fehlt mittlerweile eine Idee wonach ich suchen soll ... hat jemand einen Tipp?

Gruß
Andreas

[Wzut]

ein normales verbose 3 Log wird dir da nicht viel weiterhelfen.
Um dem Problem näher zu kommen musst du das cm Device auf verbose 5 setzen und dann deine desiredTemp in der einen Gruppe setzen und warten bis ein HT der anderen Gruppe dieses Verhalten zeigt. Im Log sollte dann schon zu finden sein warum bzw. durch welches Device dieses Verhalten aufgelöst wurde, da ein verbose 5 Log ja auch alles loggt was direkte Device-Device Kommunikation ist.
Ich habe selbet mehr als eine Gruppe und kenne dieses Problem nicht.

[arm9999]

Werde ich pobieren, habe es im verbose 4 im Moment stehen.

[arm9999]

Habe das mal in verbose 5 aufgezeichnet und sieht wie folgt aus:

Code Auswählen Erweitern

2020.12.17 14:13:03 4 : MaxGW, send -> cmd:SetTemperature, msgcnt:12, flags:04, Cmd2id:40, src:MAX_0bee01 , dst:MAX_10c86d , gid:06 , payload:22 , cul:none
2020.12.17 14:13:03 5 : MaxGW, send packet: 0b1204400bee0110c86d0622
2020.12.17 14:13:03 5 : MaxGW, Send Queue 1 packet in queue
2020.12.17 14:13:03 5 : MaxGW, Send Queue MaxCUL -> needPreamble: 1, necessaryCredit: 110, credit10ms: 731, MaxCUL CMD_LAST_H: 4
2020.12.17 14:13:03 4 : MaxGW, Send Queue packet send : Zs0b1204400bee0110c86d0622 to MAX_10c86d with MaxCUL
2020.12.17 14:13:03 4 : n_SYS_MQTT_cmnd exec { if($EVENT =~ qr/.*?: (.*)/p) { my $cmnd = $1;; Log3 ($NAME,5,"execute mqtt command : ".$cmnd);; fhem($cmnd);; } }</div>2020-12-17 14:13:03 MAX MAX_10c86d lastcmd: set_desiredTemperature 17.0 17.0
2020-12-17 14:13:03 MQTT_DEVICE SYS_MQTT cmnd: set MAX_10c86d desiredTemperature auto 17.0
2020.12.17 14:13:04 5 : MaxGW, Send Queue 1 packet in queue
2020.12.17 14:13:04 4 : CUL_Parse: MaxCUL Z0E12020210C86D0BEE01000118012207 -70.5
2020.12.17 14:13:04 5 : MaxGW, IODev MaxCUL, len 14, msgcnt 12, msgflag 02, msgType Ack, src 10c86d, dst 0bee01, group 0, payload 01180122, rssi -70.5
2020.12.17 14:13:04 5 : MaxGW, ACK from MAX_10c86d for cmd SetTemperature , packet will be removed soon
2020.12.17 14:13:04 5 : MaxGW: dispatch MAX,1,Ack,10c86d,01180122
2020.12.17 14:13:04 5 : MAX_Parse, MAX,1,Ack,10c86d,01180122
2020.12.17 14:13:04 5 : MAX_Parse, MAX2,1,WallThermostatState,10c86d,180122
2020.12.17 14:13:04 5 : MAX_10c86d, bat 0, rferror 0, panel 0, langateway 1, dst 1, mode 0, displayActualTemperature 1
2020.12.17 14:13:04 5 : MAX_10c86d, desiredTemperature 17
2020-12-17 14:13:05 MAX MAX_10c86d displayActualTemperature: 1
2020-12-17 14:13:05 MAX MAX_10c86d 17.0
2020-12-17 14:13:05 MAX MAX_10c86d desiredTemperature: 17.0
2020-12-17 14:13:05 MAX MAX_10c86d RSSI: -70.5
2020-12-17 14:13:05 MAX MAX_10c86d battery: ok
2020-12-17 14:13:05 MAX MAX_10c86d batteryState: ok
2020-12-17 14:13:05 MAX MAX_10c86d rferror: 0
2020-12-17 14:13:05 MAX MAX_10c86d gateway: 1
2020-12-17 14:13:05 MAX MAX_10c86d mode: auto
2020-12-17 14:13:05 MAX MAX_10c86d panel: unlocked
2020.12.17 14:13:05 5 : MaxGW, Send Queue 1 packet in queue
2020.12.17 14:13:05 4 : MaxGW, Send Queue ACK from MAX_10c86d for SetTemperature, removing from queue
2020.12.17 14:13:05 5 : MaxGW: dispatch MAX,1,AckSetTemperature,10c86d,17.0 17.0
2020.12.17 14:13:05 5 : MAX_Parse, MAX,1,AckSetTemperature,10c86d,17.0 17.0
2020.12.17 14:13:05 5 : MaxGW, Send Queue is now empty
2020-12-17 14:13:05 MAX MAX_10c86d lastcmd: desiredTemperature 17.0 17.0
2020-12-17 14:13:05 MAX MAX_10c86d 17.0
2020.12.17 14:13:35 4 : CUL_Parse: MaxCUL V 1.26.08 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
2020.12.17 14:14:05 4 : CUL_Parse: MaxCUL V 1.26.08 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
2020.12.17 14:14:09 3 : MaxCULcredits: MaxCUL credit10ms => 687
2020.12.17 14:14:31 4 : CUL_Parse: MaxCUL Z0F00046013F7DF0000000018002200D817 -62.5
2020.12.17 14:14:31 5 : MaxGW, IODev MaxCUL, len 15, msgcnt 00, msgflag 04, msgType ThermostatState, src 13f7df, dst 000000, group 0, payload 18002200D8, rssi -62.5
2020.12.17 14:14:31 5 : MaxGW: dispatch MAX,0,ThermostatState,13f7df,18002200D8
2020.12.17 14:14:31 5 : MAX_Parse, MAX,0,ThermostatState,13f7df,18002200D8
2020-12-17 14:14:32 MAX MAX_13f7df temperature: 21.6
2020-12-17 14:14:32 MAX MAX_13f7df deviation: 4.6
2020-12-17 14:14:32 MAX MAX_13f7df valveposition: 0
2020-12-17 14:14:32 MAX MAX_13f7df 17.0
2020-12-17 14:14:32 MAX MAX_13f7df desiredTemperature: 17.0
2020-12-17 14:14:32 MAX MAX_13f7df RSSI: -62.5
2020-12-17 14:14:32 MAX MAX_13f7df battery: ok
2020-12-17 14:14:32 MAX MAX_13f7df batteryState: ok
2020-12-17 14:14:32 MAX MAX_13f7df rferror: 0
2020-12-17 14:14:32 MAX MAX_13f7df gateway: 1
2020-12-17 14:14:32 MAX MAX_13f7df mode: auto
2020-12-17 14:14:32 MAX MAX_13f7df panel: unlocked
2020-12-17 14:14:32 MAX MAX_13f7df peerList: Broadcast,MAX_13fb19,MAX_17ed59
2020-12-17 14:14:32 MAX MAX_13f7df peerIDs: 000000,13fb19,17ed59

Gesendet wurde über FHEM an das WT 10c86d, dieser ist verbunden mi dem TH 1bd6ce, beide in Gruppe 6.
Gleich darauf reagiert aber mit einer Temperaturänderung TH 13f7df, dieser ist in Gruppe 1.

Woher kommt denn der Befehl dafür?

Ist es denn richtig, dass bei diesen Zeilen die group immer 0 ist? Hier sehe ich nie die gid bzw. ist group immer 0
>> MaxGW, IODev MaxCUL, len 14, msgcnt 12, msgflag 02, msgType Ack, src 10c86d, dst 0bee01, group 0, payload 01180122, rssi -70.5

Irgend eine Idee die mir weiterhelfen könnte?

[Wzut]

1. dein Log ist nicht leicht zu lesen :
a. keine Code Tags benutzt (ich war mal so frei deinen Post zu editieren)
b. wer ist MAX_0bee01 ? dein cm Device ?
c. was haben die MQTT Nachrichten mit MAX zu tun ?
d. das ist kein reinrassiges Log, sieht eher aus wie Event Monitor mit Log Häkchen, da Events zu sehen sind
  ( Bitte schau nochmal ins echte Logfile ob da nicht eventuell Zeilen fehlen )
e. den CUL kannst du mit verbose 2 laufen lassen dann fallen dessen Nachrichten auch schonmal raus

2. Zum Ablauf : der erste Teil sieht eigentlich gut aus , Temp setzen des WT , Ack vom WT usw.
Komisch ist -> MaxGW: dispatch MAX,1,AckSetTemperature,10c86d,17.0 17.0 diese dopplete Temperatur habe ich so noch nie gesehen, das geht bei dir durch bis MAX_10c86d lastcmd: desiredTemperature 17.0 17.0
Das 13f7df kommt erst einige Zeit später ins Spiel mit seinem State den es als Broadcast verschickt, scheint sich aber angesprochen gefühlt zu haben von den 17 °C

Die groupId ist eigentlich fast immer 0 wenn die Geräte Nachrichten als Broadcast oder an die Zentrale schicken.
Wenn ich im Modul Nachrichten zusammenbaue sende ich sie mit -> gid:06

Das Problem mit der groupId ist halt das man sie nicht auslesen kann, daher kann ich mich immer nur auf die aktuellen Readings stützen.
Da die groupID in der Original Software den Raum darstellt, habe ich schon länger die Vermutung das es beim assozieren einen Unterschied macht ob die groupId schon vorher != 0 gesetzt wurde oder erst danach. Wie war das bei dir ?

[Wzut]

Mit dem Thema flags und groupid in den Nachrichten habe ich mich bisher nie so richtig beschäftigt und alles so von meinem Vorgänger hingenommen,
frei nach dem Motto "wird schon alles so stimmen" da es auch bisher nie Klagen in dieser Richtung gab.
Trotzdem habe ich gestern Abend noch ein paar Versuche gemacht und ausgewertet. Was mir dabei auffällt :
Nachrichten die direkt von einem Gerät zum anderen gehen, haben als groupid immer die 00, ich kann mir das bisher nur so erklären das es eben keine Nachricht für mehrere Geräte ist sondern genau für eines. Ähnlich ist es mit den Flags, hier findet sich 02 aber auch 04. 04 wird z.Z. von der groupid > 0 abhängig gemacht. Da das geschilderte Problem bei einer Nachricht von CUL_MAX an ein einzelnes Gerät auftritt würde ich einfach mal die diversen Kombinationen testen und beobachten ob der Effekt auch da auftritt.
Traust du dir zu eine Änderung in der 10_MAX.pm zu machen ?
Die Zeile 747 sieht heute (svn 23290 2020-12-04 11:49:41) so aus :

Code Auswählen Erweitern

return ($hash->{IODev}{Send})->($hash->{IODev},"SetTemperature",$hash->{addr},$payload, callbackParam => $val, groupId => sprintf("%02x",$groupid), flags => ( $groupid ? "04" : "00" ));
du kannst nun mal diese Varianten testen :

Code Auswählen Erweitern

return ($hash->{IODev}{Send})->($hash->{IODev},'SetTemperature', $hash->{addr}, $payload, callbackParam => $val, groupId => '00', flags => '02');
und

Code Auswählen Erweitern

return ($hash->{IODev}{Send})->($hash->{IODev},'SetTemperature', $hash->{addr}, $payload, callbackParam => $val, groupId => '00', flags => '04');
wichtig nach jeder Änderung der Zeile in FHEM ein reload 10_MAX ausführen oder ggf. FHEM neu starten (shutdown restart) 

[Wzut]

hmmm das wird hier langsam zum Monolog ...
anyway, auf die Test mit flags 00 und flags 02 kannst du IMHO verzichten da bei mir das HT den auto/manu Mode dann nicht wechselt.
Mit flags 04 und groupid 00 dagegen schaut es gut aus bzw. ich habe halt keine Veränderung weder postiv noch negativ.

[arm9999]

Hallo,
und erstmal sorry für meine späte Antwort, aber ich hatte keine Benachrichtigung für diesen Post eingeschaltet ( ) und so deine Antworten nicht gesehen.

Kurz zu deinen Fragen:

0bee01 ist mein CM
editieren ist natürlich jederzeit OK.
Die Änderungen werde ich mal probieren, komme aber erst morgen dazu das einzubauen.

Von der Vorgehensweise habe ich die Geräte tatsächlich erst gepairt und dann die groupid vergeben. Als ich den MaxCubeLan noch im Einsatz hatte war das kein Thema, da hatte das bei den Geräten funktioniert und die Software konnte dann auch den richtigen Raum anzeigen.

Das mit der doppelten Temperaturangabe ist mir auch schleierhaft woher das kommt, wird aber in FHEM erzeugt.

Die MQTT Nachrichten erzeuge ich über FHEM und schreibe so alle Änderungen in eine Datenbank (Mosquitto) als Austauschmedium für eine andere Software. Im Grunde ganz einfach, jedes Reading wird über ein Notify nach MQTT geschrieben, so habe ich immer alle Parameter aktuell zur Verfügung. Will die andere Software was ändern, dann schreibt sie diese an eine bestimmte Stelle in MQTT und ein FHEM notify holt sich das und führt es als direkten Shell-Befehl aus.

und ja, du hast es gleich erkannt, es war kein reinrassiges LOG - da bin ich noch nicht fit drin und hatte stattdessen den EventMonitor laufen.

P.S. Frohes Neues Jahr und Danke für deine super Arbeit und Unterstützung.

[Wzut]

Lies doch bitte auch mal https://forum.fhem.de/index.php/topic,117004.0.html durch, inzwischen vermute ich bei dir ein ähnliches Problem.

Edit : Zum Thema MQTT :  machst mal bitte hier im Unterforum dazu einen neuen Thread auf und poste dort die lists von deinen notifys.
Das hat zwar vermutlich nichts mit dem Problem jetzt zu tun, aber ich würde da gerne mehr erfahren und vllt. lässt sich das auch noch optimieren und könnte für andere User ein intressanter Ansatz sein.

[arm9999]

Das mit den groupid's könnte ein Ansatz sein, den muss ich mal durchspielen. Wobei bei mir alle Geräte zurückgesetzt und neu an FHEM und MaxCube angelernt wurden.

Ich habe im Moment den Verdacht, dass die auf den HT/WT gespeicherten Daten nicht synchron zu FHEM sind. Meine Vermutung ist, dass Änderungen über FHEM gleich in die DB eingetragen und als Reading angezeigt werden, an die HT/WTs aber (noch) nichts übertragen wurde. Beim assozieren/deassozieren ist der Effekt gut sichtbar. Gibt es eine Möglichkeit ein "neueinlesen" aller Parameter für ein HT bzw. WT auszulösen, analog dem Verfahren beim pairing? Ich würde gerne mal vergleichen welche groupid und welche associate auf den HT/WT hinterlegt ist und was in der FHEM DB wirklich abgespeichert ist.

[edit] für meine MQTT Kopplung mache ich mal einen neuen Thread auf, zu finden unter:
https://forum.fhem.de/index.php/topic,117423.0.html

[Wzut]

Stichwort asynchron : Das kann gut sein. Auch mit deiner Vermutung das die quasi blind aufgrund des Set Befehls gesetzt wird stimmte lange Zeit.
Ich habe aber letztes Jahr 10_MAX so geändert das die groupid erst in den readings landet wenn vom Device das dazugehörige ACK empfangen wurde.
Ausserdem gab es vor einem Jahr noch den Fehler das die beim Re-Pairing mit 0 überschrieben wurde. Alles Sünden der Vergangenheit und man hat schlichtweg unterlassen den Leuten immer wieder klar zumachen wie wichtig dieses eine Reading ist.

Eben weil man MAX Geräte nicht wieder auslesen kann predige ich ständig alle wichtigen Parameter mittels set <name>saveConfig zu sichern und gut zu verwahren damit man im Falle X FHEM wieder synchron zum Devce bekommt. Siehe https://forum.fhem.de/index.php/topic,106258.0.html , Stichwort wichtige Readings.


 

[arm9999]

Da ich vorher den "Alzheimer" Cube hatte, war genau das lebensnotwendig Jetzt ist das geübte Praxis bei mir.

Was die Synchronität angeht versuche ich mal herauszufinden ob es da noch klemmt, mal sehen ob ich das die nächsten Tage noch schaffe.

Aktuell habe ich noch keinen Ansatzpunkt warum sich einzelne HTs angesprochen fühlen, obwohl sie nicht in der zugehörigen Gruppe sind. Irgendwie sieht es so aus, wenn ich mir das Binärmuster der Gruppen anschaue, als ob irgendwo im Code mit einer Bitmaskierung gearbeitet wird und zuvor das Carry oder die Maskierungsvariable nicht auf Null gesetzt wurde. Das Verhalten wirkt für mich systemisch, wie die Gruppen aufeinander reagieren, fast wie ein "rolling code".....

Effekt:
Gruppe 1 -> Gruppe 2
Gruppe 2 -> Gruppe 3
Gruppe 3 -> Gruppe 5
Gruppe 4 -> ------
Gruppe 5 -> ------
Gruppe 6 -> Gruppe 1

[Wzut]

Dann würde ich doch mal wie der User im anderen Thread die groupids zum Test bei zwei Gruppen so tauschen wie sie heute reagieren.
Hast du eigentlich  mal meinen Voschlag vom 19 Dezember mit flags 04 und groupid 00  getestet ?

[JHo]

Hallo Wzut,

in einem älteren Thread schreibst du

Notwendig, die groupID ist der Raum in der Original ELV Cube Firmware. IMHO schenkt die Mehrheit der User der groupID zu wenig Beachtung.

, davor ging es explizit um fake-WT bzw. -FK.

Wie ist denn der aktuelle Stand, unter welchen Umständen ist es angeraten, via FHEM groupids zu setzen? Nur MAXLAN, oder auch CULMAX, nur bei "umgezogenen" Setups von der MAX-App oder auch bei komplett in fhem angelegten Umgebungen, ...?
Ich blicke da nicht (mehr) durch, würde aber jetzt beim Neuaufbau meiner Installation (zum CUL geflashter Cube) gerne gleich alles richtig machen und vielleicht die Antwort auch gleich ins Wiki eintragen (oder ist das Thema noch work in progress?). Das Thema groupid ist da nicht besonders hilfreich beschrieben

Danke! Jan

[Wzut]

ich fang mal hinten an :
Das Thema ist deshalb nicht hinreichend beschrieben weil man jahrelang wohl wenig/nichts über dessen wahre Bedeutung wusste.
Wiki : Das MAX Wiki entählt einige Falschaussagen, es ist aber nicht auf meinem Mist gewachsen und ich werde da auch nicht anfangen zu editieren, mir reicht schon was ich in der command.ref liefern muß.

Generell : Gut dran ist wer noch MAXLAN einsetzt. Da sollten die groupids stimmen weil immer das ganze Device vom Cube an FHEM übertragen wird.
Die Betonung liegt auf "sollte" da auch ich jetzt durch die aktuellen Threads gelernt habe das der User auch den Cube durcheinander bringen kann.
Z.b. durch Cube Alzheimer und neu anlegen der Geräte ohne sie vorher einem Werksreset zu unterziehen und nicht einhalten der Raum Reifenfolge.

Wer heute CUL_MAX nutzt muss selbst prüfen was im jeweiligen Device Reading steht und ob das Sinn macht bzw. ob es die hier beschrieben Effekte bei ihm gib. Ich könnte wetten die Mehrheit der User hat versaute Readings mit 0 als groupid.

Offen ist die Frage wann die groupid unbedingt gesetzt werden muß , vor einem peering (associate) mit einem anderen Device oder danach.
Um die Frage endgültige zu klären muß ich mal wieder den Cube aktivieren zwei Geräte in einem Raum packen und zeitgleich alle Telegramme zwischen den Geräten mit einem extra CUL/CM mitschneiden.