Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

noansi · 22 März 2021, 19:15:47

Hallo Peter,

per default wird vor dem Senden geprüft, ob der Kanal frei ist. In diesen Fällen war es nicht so und der jeweilige CUL hat aufgegeben, da der Wartetimeout zugeschlagen hat.
Es macht wenig Sinn zu senden, wenn gerade ein anderes Gerät plappert (ewig zu warten aber auch nicht). Andere Geräte können HM Geräte/CULs sein, aber auch SlowRf Geräte, die auf 868.3MHz senden. Wenn es selten vorkommt, dann wird das die Ursache sein. So lange Du keine Fehlfunktionen deswegen hast, sprich Wiederholungen das abfangen, einfach damit leben.

Es kann auch sein, dass beispielsweise das versorgende Schaltnetzteil oder ein anderes Gerät mit Störabstrahlung den Kanal "verseucht". In dem Fall wäre die erste Maßnahme, den Störenfried zu identifizieren (Ausschalttests) und zu eliminieren (abschalten, Abstand vergrößern, Entstörmaßnahmen, Geräte mit fast leeren Batterien als Störsender ausschließen etc.). Solche Störungen machen sich aber auch eher längerfristig bemerkbar (es sei denn im Vorbeigehen wird man gerade mal selber Reflektor für sonst schwache Störungen). Dauersender auf Grund fast leerer Batterien gab es schon (bei mir selber, aber auch hier im Forum).

Dann kannst Du die Einstellmöglichkeiten durchprobieren, um die CCA Erkennung unempfindlicher zu machen oder abzuschalten, CCAmode, csRelThr und csAbsThr.
csRelThr und csAbsThr bestimmen die RSSI Erkennungsschwelle für Signaländerungen bzw. Absolutsignalpegel.
CCAmode = 0 -> ganz aus
CCAmode = 1 -> nur RSSI entsprechend obiger Schwellen
CCAmode = 2 -> nur wenn gerade ein Paket empfangen wird ohne RSSI Betrachtung
CCAmode = 3 -> RSSI entsprechend obiger Schwellen oder wenn gerade ein Paket empfangen

Mit mehreren TSCULs, die sich auch gegenseitig "höhren" können, macht CCA auf jeden Fall Sinn, damit sie sich möglichst nicht gleichzeitig sendend stören (dann verlieren beide, wohingegen mit CCA wenigsten einer erfolgreich übertragen kann). Von daher besser an den Schwellen drehen und versuchen den besten Kompromiss zu finden, sofern es ein Funktionsproblem darstellt.

ZitatIch betreibe 2 HMLAN, 1 CUNO V2 sowie einen CUL V3 über ser2net. Angebunden sind etwa 90 Homematic-Komponenten.

Nutzt Du meine CUL_HM und Co. Sondermodule oder die Standard-HM-Module aus dem Update/SVN?
Wäre ja mal ein schönes aktuelles Feedback, wenn der Mischbetrieb mit HMLAN auch mit aktuellem Stand meiner Sondermodule problemlos funktioniert, da ich selber nur mit CULs lebe und teste. (HMLAN macht vermutlich kein CCA, dürfte also immer dazwischen plappern, wenn es was zu senden hat).

Gruß, Ansgar.

pte · 22 März 2021, 21:10:21

Hallo Ansgar,

danke für deine ausführlichen Erläuterungen. Die muss ich jetzt erst mal "verdauen".
Zu deiner Frage bezüglich CUL_HM-Modulen muss ich leider zugeben, diese aktuell nicht einzusetzen, da ich noch mit den Umstellungen infolge Wegfall von diversen "doppelten" Readings (actuator, measured-temp, desired-temp) beschäftigt bin (hatten wir vor kurzem hier diskutiert).
Ich hoffe aber, in den nächsten Tagen damit durch zu sein und dann werden ich auch deinen Modulstand zu 10_CUL_HM, HMInfo, HMConfig und 98_HMtemplate einspielen.

Da die Ereignisse ja relativ selten (heute waren es 3) und sowohl beim Cuno als auch beim CUL auftreten, glaube ich nicht so richtig an die Verseuchung durch Schaltnetzteile, auch wenn sich in der Nähe von beiden durchaus welche befinden. Der Cuno sitzt im betonierten und armierten Heizungskeller, der CUL im Garten in einem Schuppen, decken also auch sehr unterschiedliche Bereiche ab. SlowRf Geräte, die auf 868.3MHz senden, betreibe ich nicht. Beide überlappen sich jedoch mit den HMLAN's, was ich aus den RSSI-Werten von Geräten in der Nähe der Cuno/CUL im Vergleich zu denen der HMLAN ableite.

Aufgefallen ist mir noch, dass im log vor den Fehlern 3x der gleiche Befehl versucht wurde abzusetzen (hatte ich nicht mit kopiert).

Code Auswählen

2021.03.22 11:05:58.405 3: CUL_HM set Regensensor_Heating on noArg
2021.03.22 11:05:58.984 3: CUL_HM set Regensensor_Heating on noArg
2021.03.22 11:05:59.119 3: CUL_HM set Regensensor_Heating on noArg
2021.03.22 11:05:59.313 3: LogHist GASCCUL:  06635133 A F001 00843380 00 0E B1 8202 149DAC 18134A 010100004A -83dB

Kann man daraus noch etwas schlussfolgern?

Gruß Peter

noansi · 23 März 2021, 20:44:23

Hallo Peter,

ZitatDie muss ich jetzt erst mal "verdauen"

Sorry für die harte Kost, aber das sind nun mal die Optionen.

Ich gehe auch eher davon aus, dass es sich auf Grund der geringen Häufigkeit um effektiv unkritische normale Kanalkollisionen handelt. D.h. Du könntest nur mal mit den Parametern spielen, um eventuell etwas unempfindlicher bezüglich weit entfernten devices zu werden.
Natürlich kannst Du auch mal vergleichen, ob CCAmode 0 problematischer, unproblematischer oder gleich ist, aber erkennbar dann nur an ggf. eher ausbleibenden Sensordaten und eher auftretenden Schaltfehlern.

ZitatKann man daraus noch etwas schlussfolgern?

Nein. Setzt Du die 3 mal so kurz hintereinander ab?

Gruß, Ansgar.

noansi · 23 März 2021, 21:41:21

Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 aktualisiert.

TC statusRequest.

Gruß, Ansgar.

noansi · 04 April 2021, 14:35:32

Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 aktualisiert.

Korrekturen Registeread, Pairing, AES und IO Zuweisung.

Gruß, Ansgar.

noansi · 04 April 2021, 23:42:51

Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 aktualisiert.

Korrekturen IO Zuweisung und IOgrp 'none' Option.

Gruß, Ansgar.

pte · 05 April 2021, 15:19:33

Hallo Ansgar,

kannst du mal eine Liste veröffentlichen, welche Readings in welchen Channels aktuell gepflegt werden.
Ich hatte nach den letzten Änderungen z.B. erwartet, dass measured-temp im Weather-Channel gepflegt wird. Dort wird es aber nicht mehr aktualisiert. Die Änderungen finden sich nur im Climate-Channel.

Gruß Peter

noansi · 05 April 2021, 16:30:59

Hallo Peter,

für HM-CC-RT-DN:

Device:
motorErr
battery
batteryLevel

Clima Channel (04):
desired-temp
measured-temp
ValvePosition
boostTime
partyStart
partyEnd
partyTemp
controlMode

Ich hoffe, das macht es jetzt klar.

Gruß, Ansgar.

pte · 05 April 2021, 16:36:48

Ok. Danke.
Dann mal noch schöne Ostern.

Gruß Peter

pte · 06 April 2021, 16:59:24

Hallo Ansgar,

ich möchte noch einmal zu Bedenken geben, ob die Entscheidung, measured-temp für die HM-CC-RT-DN nur noch im Climate-Channel zu aktualisieren, richtig ist. Sowohl bei den älteren HM-CC-TC als auch bei den HM-TC-IT-WM-W-EU werden die Werte für measured-temp und humidity zumindest aktuell noch in den Weather-Channel's aktualisiert, wo ich sie auch für richtiger finde.
Bitte noch einmal darüber nachdenken.

Gruß Peter

noansi · 07 April 2021, 19:53:20

Hallo Peter,

mir ist wichtig, dass zur normalen Laufzeit nur einmal ein Event für die selbe Information erzeugt wird, denn jedes Event erzeugt Rechenbedarf. Der lässt sich nur über eine sinnvolle Wahl bei event-on-change-reading und event-on-update-reading verringern, aber nicht ganz vermeiden.

Im Clima Channel ist alles beisammen, was zur Regelung beiträgt.
Weather Channel ist beim RT ein Empfangskanal für Temperatur (ggf. und Luftfeuchtigkeit) eines externen Sensors. Da würde ich sie aktualisieren, wenn nur die von einem externen Sensor empfangenen Werte auf dem Channel signalisiert würden.
Leider sendet der RT nur die Temperatur, die er gerade zu Regelung verwendet. Wenn er von extern nichts empfängt, schaltet er um auf die interne Temperatur und sendet die.
Daher nach meinem Empfinden logisch richtiger im Clima Channel.

Wenn Du aber unbedingt Werte im Weather Channel haben willst, kannst Du Dir die 5 Zeilen Code im Quelltext auch wieder aktivieren. Ich habe sie nur auskommentiert. Such nach "#weather Chan".
Allerdings setze ich da für state auch peered/unpeered, analog zu anderen Channels.

Gruß, Ansgar.

riker1 · 08 April 2021, 09:58:50

Hi,

eine Frage.

das Reading

Code Auswählen

CommandAccepted

wird im filelog nicht geloggt und erzeugt keinen Event?

Habe ich da was übersehen?

Attribute ist gesetzt.

Code Auswählen

event-on-update-reading .*

Danke VG T

noansi · 08 April 2021, 18:53:43

Hallo T,

ja, es wird für das Reading CommandAccepted kein Event erzeugt.
Das ist in der Standard CUL_HM genauso. Also ein rein informatives Reading zum anschauen.

Gruß, Ansgar.

riker1 · 08 April 2021, 19:48:45

Zitat von: noansi am 08 April 2021, 18:53:43
Hallo T,

ja, es wird für das Reading CommandAccepted kein Event erzeugt.
Das ist in der Standard CUL_HM genauso. Also ein rein informatives Reading zum anschauen.

Gruß, Ansgar.

alles klar danke.

Habe das Problem das zuviele commands pending sind und die devices immer wieder missing sind.
Dachte könnte damit eine bessere Kontrolle über den Erfolg haben".

Denke mache das dann über das HM hauptdevice mit state CMDs_Pending und so.

Muss nochmal recherchieren warum so viele Fehler da sind.

Danke erstmal VG T

yersinia · 30 April 2021, 09:30:48

Hier mal ein Feedback zu dem Thema Optiboot und alter Bootloader:

Zitat von: noansi am 09 März 2021, 20:11:19ok, meine Vermutung zur Bootloader Loop nach Watchdog Reset hat wohl gepasst.
Schön, dass Du den Optiboot Hinweis schon gefunden hast.

Der Watchdog kann bei jeder Firmware Variante zuschlagen, wenn gleich ich versucht habe, dies für den Normalbetrieb nach Möglichkeit in der tsculfw zu vermeiden. Sprich Warten mit Timeout, statt warten, bis der Watchdog zuschlägt.

Dann gibt es auch noch die Möglichkeit des Pufferüberlaufs bei der seriellen Übertragung auf CUL Seite. Und da ASKSIN immer mit HEX Daten als Befehl versorgt wird, kann das prinzipiell im ungünstigen Fall zu Datensalat führen bei dem auch ein B00 statt des gewünschten Befehls ausgeführt wird -> auch ein Watchdog Reset. Gilt auch für jede Firmware Variante. Allerdings müssen dazu mehrere Befehle hintereinander ohne Pause an den seriell angebunden CUL gesendet werden.
In TSCUL gibt es aber Bremsmechanismen, so dass der Zustand nicht eintreten sollte.
Xon/Xoff für die serielle Übertragung war noch nie in einer der Firmware Varianten implementiert, so weit ich das gesehen habe (und möchte ich wegen SlowRf auch nicht in die tsculfw einbauen).

In beiden Fällen muss der CUL also diese Watchdog Reset "überleben", was bei einem problematischen Bootloader beim nano offenbar schief geht.

Nach reiflicher Testzeit zeigt der ser2net-nanoCUL folgende uptime:

Code Auswählen

44 19:53:33
Der nanoCUL am RasPi wird mit jedem FHEM restart (1x wöchentlich) neu initialisiert, der ser2net-nanoCUL allerdings nicht. Von solchen Laufzeiten habe ich vorher mit altem Bootloader nur träumen können (ob die aculfw darauf Einfluss hatte, kann ich nicht beurteilen).

EDIT 2021-07-27:

Code Auswählen

132 21:10:26