Kombimodus ohne Pollen ?

[marc2]

Moin !

Ich fahre seit langer Zeit CUL_MAX und MAXLAN parallel, wobei die Devices mit CUBE gepaired
sind. Da der CUL ja alles was die Devices so von sich geben mitbekommt, sollte es doch
möglich sein, dass Pollinterval des CUBEs auf 0 oder sehr hoch zu setzen und ihn nur noch zum
Senden von Änderungen zu nutzen, oder ? Dieses ständige Pollen finde ich recht unschön ...

Wie sind die Erfahrungen im CUL_MAX only Modus (ganz ohne CUBE)? Spricht ausser dem Aufwand,
alles neu Pairen zu müssen etwas dagegen ?

Gruß, Marc

[marc2]

Moin!

Ich habe von meinen 11 Thermostaten heute testweise mal einen aus der MAXLAN
konfiguration rausgenommen und mit dem CUNO neu gepairt. Soweit keine Probleme.
Um 23:00 wurde dann - wie jeden Tag - auf ECO umgestellt, mit folgenden Logeinträgen:

Code Auswählen Erweitern

2013.03.10 23:00:02 1: CUL_MAX_Parse: len mismatch
2013.03.10 23:00:03 1: CUL_MAX_Parse: len mismatch
2013.03.10 23:00:04 1: CUL_MAX_Parse: len mismatch
2013.03.10 23:00:07 1: cuno2:2323 disconnected, waiting to reappear
Argument "No answer" isn't numeric in numeric lt (<) at ./FHEM/14_CUL_MAX.pm line 414.
2013.03.10 23:00:12 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is No answer, but we need 110. Waiting 110 seconds.
2013.03.10 23:00:17 1: cuno2:2323 reappeared (CUNO2)
2013.03.10 23:00:17 3: CUNO2: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2013.03.10 23:00:26 2: CUNO2: unknown message 203122001EE63000119042032

Das "Not enough credit" schockt mich, da es wie gesagt nur ein einzelner Thermostat ist und
ich diesen nicht - mutwillig - ständig polle. FHEM läuft MAX mäßig auf der aktuellsten
Version.

Gruß, Marc

[Matthias Gehre]

Da steht, dass dein CUNO verschwunden ist, daraufhin die credits nicht ausgelesen wurden konnten.
Aber senden ohne CUNO hätte ja eh nicht geklappt.

[marc2]

Hallo Matthias,

das ist zwar korrekt, aber die Ursache ist jeweils das Umschalten auf ECO, bzw. Comfort. Das
Umschalten wird getriggert gefolgt von den Meldungen (zuletzt um 19:00 Uhr):

Code Auswählen Erweitern

2013.03.11 19:00:02 1: CUL_MAX_Parse: len mismatch                                                                                  
2013.03.11 19:00:03 1: CUL_MAX_Parse: len mismatch                                                                                  
2013.03.11 19:00:04 1: CUL_MAX_Parse: len mismatch                                                                                  
2013.03.11 19:00:07 1: cuno2:2323 disconnected, waiting to reappear                                                                
2013.03.11 19:00:12 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is No answer, but we need 110. Waiting 110 seconds.  
2013.03.11 19:00:17 1: cuno2:2323 reappeared (CUNO2)                                                                                
2013.03.11 19:00:17 3: CUNO2: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq  

Der CUNO scheint also bei jedem Umschalten ein Prolem zu bekommen (reboot ?)

Die CUNO Firmware ist recht neu:

Code Auswählen Erweitern

? (h is unknown) Use one of m B C F Z i A G M R T V W X O e f l t u H x E c q
V
V 1.53 CUNO868

Gruß, Marc

[marc2]

So,

ich habe den CUNO noch einmal auf den aktuellsten SVN Stand gebracht (auch wenn die
Version bei 1.53 geblieben ist). Schaun wir mal. Mag sein, dass es daran liegt, dass
der CUBE quasi zeitgleich die übrigen 10 Thermostate umschaltet !? Wenn es wieder
passiert, werde ich mal die Uptime des CUNO checken. Sieht auf den ersten Blick
wirklich immer nach einem Reboot aus.

Gruß, Marc

[marc2]

Nachtrag, das vom CUBE auf CUL umgezogene Thermostat habe ich natürlich
per FaktoryReset zurückgesetzt und mit dem CUL (CUNO) neu gepairt. FHEM
zeigt mir als IODev auch eindeutig "cm" und nicht mehr "ml" an. Kann es sein,
dass der CUBE das Thermostat aber trotzdem noch kennt und sich in die
Kommunikation zwischen CUL und Thermostat einmischt ? Nach einem FactoryReset
des CUBEs wäre dann aber wohl alles weg (auch das Pairing aller anderen
Thermostate), oder ? Vielleicht wäre ein Big Bang (CUBE abschalten und alles
neu mit CUL paieren) das beste ....

Gruß, Marc

[Matthias Gehre]

Wenn du verbose auf 5 stellst, dann sind 1. deine Logs informativer, und 2. siehst du ob der Cube mit den Thermostaten redet.

[marc2]

Hallo Matthias,

das "verbose 5" log hänge ich mal dran (ist recht lang). Für mich sieht es eindeutig danach aus,dass sich der
CUBE hier nicht einmischt. Das "set HZ_Schlafzimmer desiredTemperature eco" geht über den
CUNO2 raus, der ein Problem mit der Anwort des Thermostates zu haben scheint und sich dann
für einige Sekunden "abmeldet". Rebooten tut er nicht, die Uptime ist bei rund 27 Stunden.
Das paßt, da ich den CUNO2 gestern Abend noch einaml mit der aktuellsten Firmware aus dem
SVN versorgt habe.

Das Kommando wurde vom Thermostat allerdings korrekt umgesetzt. Anzumerken ist noch, dass
das gleiche Kommando manuell (ohne, dass sich der CUBE parallel um die übrigen
Thermostate kümmert) problemlos läuft. In diesem Fall sieht das Log wie folgt aus:

Code Auswählen Erweitern

2013.03.12 23:31:02 5: Cmd: >set HZ_Schlafzimmer desiredTemperature eco<
2013.03.12 23:31:02 5: CUL_MAX_Send: enqueuing 0b200040123456017b9b0060
2013.03.12 23:31:02 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.12 23:31:02 5: SW: X
2013.03.12 23:31:02 5: CUL/RAW (ReadAnswer): 21  900

2013.03.12 23:31:02 5: needPreamble: 1, necessaryCredit: 110, credit10ms: 900
2013.03.12 23:31:02 5: CUNO2 sending Zs0b200040123456017b9b0060
2013.03.12 23:31:02 5: SW: Zs0b200040123456017b9b0060
2013.03.12 23:31:02 5: Triggering HZ_Schlafzimmer (1 changes)
2013.03.12 23:31:02 5: Notify loop for HZ_Schlafzimmer desiredTemperature eco
2013.03.12 23:31:03 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.12 23:31:03 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.12 23:31:03 5: CUL/RAW: /Z0E200202017B9B1234560001190A2021

2013.03.12 23:31:03 5: CUNO2: Z0E200202017B9B1234560001190A20 -57.5
2013.03.12 23:31:03 5: CUNO2 dispatch Z0E200202017B9B1234560001190A20
2013.03.12 23:31:03 5: CUL_MAX_Parse: len 14, msgcnt 20, msgflag 02, msgTypeRaw Ack, src 017b9b, dst 123456, groupid 0, payload 01190A20
2013.03.12 23:31:03 5: cm dispatch MAX,1,Ack,017b9b,01190A20
2013.03.12 23:31:04 5: MAX_Parse MAX,1,Ack,017b9b,01190A20
2013.03.12 23:31:04 5: MAX_Parse MAX,1,ThermostatState,017b9b,190A20
2013.03.12 23:31:04 5: battery 0, rferror 0, panel 0, langateway 1, dstsetting 1, mode 1, valveposition 10 %, desiredTemperature 16, until , curTemp
2013.03.12 23:31:04 5: Triggering HZ_Schlafzimmer (5 changes)


Gruß, Marc

[marc2]

Hi !

So nach einer weiteren Analyse sieht es für mich doch so aus, als würden die Meldungen des CUBE
den CUNO durcheinander bringen. Der CUBE ist der 01EE63, 017A35 und 017810 sind andere Thermostate,
die mit dem CUBE gepairt sind. Dass der CUNO diese Nachrichten liest verstehe ich ja noch, aber
warum versucht er sie zu parsen, obwohl er eindeutig nicht der Empfänger ist und es sich auch nicht
um Broadcasts handelt ? Weiter unten scheint der CUBE dann Messages von sich zu geben, die unvollständig
sind (z.B. Z0B41004001EE63017C1000601A). Der CUNO kann das nicht parsen und verabschiedet sich
temporär. Letzteres und die Tatsache, dass ihm dadurch die Credits ausgehen verstehe ich allerdings
nicht. Hat jemand eine Idee ?

Gruß, Marc

Code Auswählen Erweitern

2013.03.12 23:00:01 5: Cmd: >set HZ_Schlafzimmer desiredTemperature eco<
2013.03.12 23:00:01 5: CUL_MAX_Send: enqueuing 0b1f0040123456017b9b0060
2013.03.12 23:00:01 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.12 23:00:01 5: SW: X
2013.03.12 23:00:01 5: CUL/RAW (ReadAnswer): Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 5: CUNO2: Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 5: CUNO2 dispatch Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 1: CUL_MAX_Parse: len mismatch
2013.03.12 23:00:02 5: CUL/RAW (ReadAnswer): Z0B2A004001EE63017810006219
Z0E2A020201781001EE6300011918220B

2013.03.12 23:00:02 5: CUNO2: Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900
Z0B2A004001EE63017810006219
Z0E2A020201781001EE6300011918220B

2013.03.12 23:00:02 5: CUNO2 dispatch Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900
Z0B2A004001EE63017810006219
Z0E2A020201781001EE6300011918220B

2013.03.12 23:00:03 1: CUL_MAX_Parse: len mismatch
2013.03.12 23:00:04 5: CUL/RAW (ReadAnswer): Z0B41004001EE63017C1000601A
Z0E410202017C1001EE63000119102013

2013.03.12 23:00:04 5: CUNO2: Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900
Z0B2A004001EE63017810006219
Z0E2A020201781001EE6300011918220B
Z0B41004001EE63017C1000601A
Z0E410202017C1001EE63000119102013

2013.03.12 23:00:04 5: CUNO2 dispatch Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900
Z0B2A004001EE63017810006219
Z0E2A020201781001EE6300011918220B
Z0B41004001EE63017C1000601A
Z0E410202017C1001EE63000119102013

2013.03.12 23:00:04 1: CUL_MAX_Parse: len mismatch
2013.03.12 23:00:07 1: cuno2:2323 disconnected, waiting to reappear

[Matthias Gehre]

Erst mal: Der CUNO parst das nicht, "len mismatch" kommt von FHEM.

Der Fehler scheint während Zeile 411 14_CUL_MAX aufzutreten.
(Kannst du durch das hinzufügen von ein paar Logs leicht verifizieren). Das MAX Modul
möchte die restlichen Credits wissen. 00_CUL.pm schickt daraufhin
den Befehl "X"
  2013.03.12 23:00:01 5: SW: X
und erwartet eine Antwort der Form "21  900".
Leider schickt der CUNO vor der Anwort noch die zwei Pakete
  Z0BC7004001EE63017A35006019
  Z0EC70202017A3501EE63000119162001
was alles etwas durcheinander bringt. Die Pakete werden zwar trotzdem
von CUL_Parse abgehandelt (während CUL_MAX noch auf die credits wartet),
allerdings wird das letzte Byte (die RSSI) nicht von CUL_Parse abgeschnitten
(was es normalerweise tut), wodurch CUL_MAX "len mismatch" meldet.

Komischerweise kommen während dem Warten auf die Antwort auf den Befehl "X"
jede Menge Pakete vom MAX Geräte rein. Ich nehme mal an, dass der Fehler in
CUL_ReadAnswer($$$$) liegt. Das während dem Warten auf Anwort soviele andere
Pakete dazwischen kommen, ist wahrscheinlich nicht so gut getestet und daher
möglicherweise fehlerhaft.
Frag mal den 00_CUL Entwickler.

[marc2]

Hi !

Das Abschneiden des RSSI mach ja CUL_Parse, Das Regex /^[AFTKEHRStZ]([A-F0-9][A-F0-9])+$/
sieht aber kein "\n" vor. DevIo_SimpleRead reicht aber scheinbar die drei Nachrichten
am Stück, also eine einzige Nachricht hoch (inkl. der zugehörigen "\n"):

Code Auswählen Erweitern

2013.03.12 23:00:01 5: Cmd: >set HZ_Schlafzimmer desiredTemperature eco<
2013.03.12 23:00:01 5: CUL_MAX_Send: enqueuing 0b1f0040123456017b9b0060
2013.03.12 23:00:01 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.12 23:00:01 5: SW: X
2013.03.12 232013.03.12 23:00:01 5: Cmd: >set HZ_Schlafzimmer desiredTemperature eco<
2013.03.12 23:00:01 5: CUL_MAX_Send: enqueuing 0b1f0040123456017b9b0060
2013.03.12 23:00:01 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.12 23:00:01 5: SW: X
2013.03.12 23:00:01 5: CUL/RAW (ReadAnswer): Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 5: CUNO2: Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 5: CUNO2 dispatch Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 1: CUL_MAX_Parse: len mismatch:00:01 5: CUL/RAW (ReadAnswer): Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 5: CUNO2: Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 5: CUNO2 dispatch Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001
21  900

2013.03.12 23:00:01 1: CUL_MAX_Parse: len mismatch

Da DevIo_SimpleRead so wie ich das verstehe direkt aus aus dem Buffer des CUNOs liest, würde ich fast vermuten,
dass das Problem in der culfw zu suchen ist. Sollte hier nicht immer genaue eine Zeile, die jeweils eine Message
repräsentiert, zurückgeliefert werden ?

Die beiden Nachrichten

Code Auswählen Erweitern

Z0BC7004001EE63017A35006019
Z0EC70202017A3501EE63000119162001

die der CUNO zwischendrin empfängt kommen vom CUBE bzw. sind die Anwort eines
Devices zum CUBE. Wo sie herkommen ist klar. Die Frage ist, warum sie zusammen vom CUNO
zusammen mit der "21 900" als eine einzige Nachricht hochgereicht werden.

Hat jedmand eine Idee ?

Danke & Gruß, Marc

[Matthias Gehre]

Die culfw hat keinen Buffer, das geht direkt über das serielle Interface in den Kernel Buffer auf Host-seite.
Mehrere Nachrichten zu haben ist also kein Fehler und wird normalerweise auch richtig verarbeitet:
FHEM's 00_CUL sollte die Nachrichten am newline (\n) trennen und einzeln verarbeiten.

[marc2]

Hallo Matthias !

Vielen Dank für die Anwort ! Da ich mich mittelfristig eh vom CUBE trennen wollte, habe
ich das aktuelle Problem zum Anlass genommen, alle MAX Devices auf CUL umzustellen. Bei
10 Thermostaten und noch mehr Shutter Kontakten sind mir dabei doch sehr häufig die Credits
ausgegangen ...

Grundsätzlich hat die Umstellung aber problemlos funktioniert. Eine Frage habe ich
jedoch noch zu den Shutter Kontakten. Diese sind ja ansich grundsätzlich im Schlafmodus.
Wenn ich für einen Shutter Kontakt die GroupId setzen oder ihn mit einem HT assoziieren
will, erhalte ich grundsätzlich ein "Missing ack".

Code Auswählen Erweitern

2013.03.29 15:57:50 1: SW: X
2013.03.29 15:57:50 1: SW: Zs0b04002212345605e5af0007
2013.03.29 15:57:53 2: CUL_MAX_SendQueueHandler: Missing ack from 05e5af for 0b04002212345605e5af0007
2013.03.29 15:57:58 1: CUNO2: Z0C6D04420312200178A30028BC -50
2013.03.29 15:57:58 1: CUNO2: Z0E6D02020178A30312200001190E28 -36.5

Der Befehl wird offensichtlich nicht in die Queue gestellt und gewartet, bis sich das Device das
nächste Mal meldet (wie es bei vergleichbaren HM Devices wäre), sondern sofort gesendet. Der Shutter
Kontakt wird stattdessen wohl per Burst geweckt. Entsprechend wundert mich das "Missing Ack"
Die Assoziation wird dabei aber scheinbar trotzdem übernommen, die grouid jedoch nicht.
Ist dieses Verhalten normal ?

Gruß, Marc

[Matthias Gehre]

Ich glaube nicht, dass man ShutterContacts per Burst wecken kann. Man müsste wirklich bis zu einer nächsten Meldung warten
(wozu einen die offizielle Software auch auffordert), aber das ist bisher nicht implementiert.
Patches sind willkommen :-)