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

noansi · 04 März 2021, 20:13:37

Hallo Testwillige,

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

Edit:
- TSCUL: alive Ping Interval für Netzwerk angebundene CULs etwas reduziert
- HMConfig: Martins Änderungen und TC StatusRequest Korrekturen
- CUL_HM: Martins Änderungen + Korrekturen, Alive Check für MultiChannel Devices nurn noch mit StatusRequest auf einem Channel
- was ich schon wieder vergessen habe...

Gruß, Ansgar.

Adimarantis · 04 März 2021, 20:46:38

Hi Ansgar,

gibt's eine kurze Zusammenfassung der Änderungen?

Danke,
Jörg

yersinia · 05 März 2021, 09:48:54

Hallo zusammen,

gibt es auch eine Kurzübersicht (for dummies

) welche Vorteile die tsculfw für den CUL gegenüber aculfw hat?
Zu meinem Setup: ich nutze für eine reine HomeMatic classic Umgebung zwei nanoCULs mit aculfw 1.26.08 und habe nur wenig Probleme (eigentlich hängen sich 'nur' die nanoCULs unregelmässig und schlecht vorhersagbar auf, daher auch zwei und die VCCU) bisher. Siehe auch Signatur bezgl. der verwendeten Aktoren & Sensoren. Ich nutze keine originalen HM IOs.
Ich habe jetzt nicht alle Seiten dieses Threads gelesen - ist bei derzeit 80 Seiten auch etwas viel - und das Wiki gibt auch nicht viel her. Den letzten Changelog habe ich überflogen aber mir ist immernoch nicht klar, warum ich die tsculfw nutzen sollte.
Kann dies jemand kurz zusammenfassen - oder auf eine Doku stoßen (wenn es ein RTFM-PEBKAC Problem ist

)?

Besten Dank.

noansi · 06 März 2021, 13:50:44

Hallo yersinia,

Zitatgibt es auch eine Kurzübersicht (for dummies ) welche Vorteile die tsculfw für den CUL gegenüber aculfw hat?

HM classic hat mit Bezug auf FHEM recht knappe Anforderungen bezüglich Antworttiming und Sendetiming. Insbesondere zu batteriebetriebenen devices kommt es zu Kommunikationsproblemen, wenn diese verletzt werden.
- a-culfw: reichhaltige Unterstützung für SlowRf Protokolle, Portierung auf nicht ATmega Hardwareplattformen. Für HM wenig geeignet mangels Unterstützung für HM-Timing und HM-AES Signierung -> starke Anfälligkeit für FHEM Laufzeitunterschiede und auch kurze FHEM freezes
- tsculfw: verbesserte Stabilität, Verbesserungen bezüglich SlowRf Empfang und Senden. Für HM Unterstützung für HM-Timing und HM-AES Signierung -> verringerte Anfälligkeit für FHEM Laufzeitunterschiede und kurze FHEM freezes. Angepasste und neue FHEM-Module zur Nutzung mit der tsculfw Firmware. Frequenzoffset einstellbar.

Zitateigentlich hängen sich 'nur' die nanoCULs unregelmässig und schlecht vorhersagbar auf

Wie äußert sich das? Was sagt uptime, wenn sie "hängen"?
Wenn die nanoCULs von schlechter Hardwarequalität sein sollten, kann die Firmware da vermuzlich nichts dran retten.

Code Auswählen

ser2net
Hoffentlich über LAN und nicht über WLAN.

Zitataber mir ist immernoch nicht klar, warum ich die tsculfw nutzen sollte.

Wenn Du Probleme bekommst und im Homematic Forum die Empfehlung bekommst diese Firmware zu nutzen oder ein originales HM-IO.

ZitatKann dies jemand kurz zusammenfassen - oder auf eine Doku stoßen

Post Nummer 1 plus 80 Seiten Thread, eventuell von hinten nach vorne durchgehen. Suchfunktion kann auch helfen.

Vor einem Test Rückweg vorbereiten. Backup FHEM. Alte Firmware nanoCULs als .hex bereit halten.

Wenn Deine nanoCULs eine abweichende Beschaltung aufweisen, board.h anpassen, compilieren und auf die nanoCULs flashen. Ansonsten TSnanoCUL.hex aus der zip auf die nanoCULs flashen.
Module durch Module aus zip austauschen. fhem.cfg anpassen. FHEM neu starten.

Gruß, Ansgar.

pte · 06 März 2021, 14:14:40

Hallo noansi,

ich hatte gestern ein Update von TSCUL auf die Version 38 einschließlich der erforderlichen FHEM-Module (sowie auch deine 10_CUL_HM, 98_HMInfo, 98_HMtemplate und HMConfig) vorgenommen. Danach habe ich festgestellt, dass bei meinen HM-CC-RT-DN im Device die Readings actuator, desired-temp und measured-temp nicht mehr aktualisiert wurden. Die korrespondierenden Werte im Channel04 (ValvePosition, desired-temp und measured-temp) waren aktuell. Der Einsatz der Standard 10_CUL_HM,... behob das Problem wieder.
Ich kann nicht sicher sagen, ob das Problem schon in früheren Versionen deiner 10_CUL_HM auftrat, da ich bisher nur die zwingenden Dateien zum TSCUL genutzt hatte.

Viele Grüße pte

noansi · 06 März 2021, 14:45:22

Hallo pte,

das ist kein Fehler (für Dich jetzt möglicherweise als Problem wahrzunehmen), sondern eine beabsichtigte Einsparung redundanter events.
Die Daten sind im Clima channel zu finden und werden dort auch aktualisiert, wie auch in Martins Standard 10_CUL_HM.pm (den Hinweis dazu gab's schon bei der V0.37, Edit: hab ich jetzt auch in den Hinweisen zur V0.38 zu 10_CUL_HM.pm ergänzt).
Sie machen dort auch logisch Sinn und nicht im device.

Da ich HM-CC-RT-DN auch selbst nutze, wird das in meiner Sonderversion auch definitv so bleiben.
Ggf. müßtest Du auf die entsprechenden Events im Clima Channel lauschen, statt auf die im device.

Gruß, Ansgar.

pte · 06 März 2021, 14:59:53

Hallo noansi,

danke für die schnelle Rückmeldung. Den Hinweis habe ich dann wohl überlesen.
Wenn dies so beabsichtigt ist, kein Problem, das kann ich bei mir ändern.

Schönes WE

pte · 07 März 2021, 10:57:20

Hallo Ansgar,

doch noch eine Frage. Entfallen damit zukünftig auch die entsprechenden Readings im Device (actuator,..)? Ich habe feststellen müssen, dass der Änderungsaufwand bei mir doch umfangreicher ist und ich würde mir dann vorerst userReadings anlegen.

Gruß Peter

noansi · 07 März 2021, 11:28:26

Hallo Peter,

Zitatdoch noch eine Frage. Entfallen damit zukünftig auch die entsprechenden Readings im Device (actuator,..)?

Ja. Tun sie ja jetzt schon, denn nicht Aktualisieren ist gleichbedeutend mit entfallen.

Mit userReadings kannst Du sie Dir selbst erzeugen. Ist natürlich kontraproduktiv zur eigentlichen Intention, redundante events zu vermeiden, aber wenn es bei Dir nicht stört, ist es eine Ausweichmöglichkeit.

Gruß, Ansgar.

pte · 07 März 2021, 11:30:45

Hallo Ansgar,

also bei mir waren die Readings nach dem Update noch da. Muss man diese selbst löschen?
Betrifft es außer actuator, measured-temp und desired-temp noch weitere?

Peter

noansi · 07 März 2021, 11:52:01

Hallo Peter,

actuator (entspricht ValvePosition im clima channel), desired-temp, measured-temp beim device eines HM-CC-RT-DN.

Ich lösche die Readings nicht automatisch (beim Neustart), könnte ich natürlich noch ergänzen, wenn notwendig. Für userReadings wäre das möglicherweise kontraproduktiv.

Gruß, Ansgar.

pte · 07 März 2021, 13:06:30

Hallo Ansgar,

ich sehe das Löschen auch kontraproduktiv (auch in Hinblick auf meine Behelfslösung).
Ich bin bei meiner Überarbeitung noch auf eine Frage gestoßen (ich befürchte hier zwar out of Topic, stelle sie aber trotzdem mal).
Es betrifft das Zusammenspiel von HM-TC-IT-WM-W-EU und HM-CC-RT-DN bezüglich Wochenprogramme.
Gepeert sind ja die Channels 02, die Wochenprogramme im HM-CC-RT-DN liegen ja aber im Channel 04. Spielen diese bei Kopplung mit einem HM-TC-IT-WM-W-EU noch eine Rolle?

Peter

noansi · 07 März 2021, 14:09:54

Hallo Peter,

ZitatEs betrifft das Zusammenspiel von HM-TC-IT-WM-W-EU und HM-CC-RT-DN bezüglich Wochenprogramme.

Ja, hier off Topic.
Und da ich keinen HM-TC-IT-WM-W-EU habe, habe ich mir darum auch noch keine Gedanken gemacht, was der so alles an gepeerte RTs überträgt.

Wäre wohl eine Frage im Homematic Forum, wenn die Anleitungen dazu keine Auskunft bieten, denke ich.
Respektive, führt eine Änderung am HM-TC-IT-WM-W-EU Programm zu einer Änderung am HM-CC-RT-DN (get config im HM-CC-RT-DN clima channel nach etwas Wartezeit)?
Schon mal probiert, die Batterien am HM-TC-IT-WM-W-EU zu entfernen und dann zu schauen, ob der RT nach einer Weile autonom mit seinem Wochenprogramm weiter macht?

Gruß, Ansgar.

yersinia · 07 März 2021, 20:15:33

Zitat von: noansi am 06 März 2021, 13:50:44
Hallo yersinia,

HM classic hat mit Bezug auf FHEM recht knappe Anforderungen bezüglich Antworttiming und Sendetiming. Insbesondere zu batteriebetriebenen devices kommt es zu Kommunikationsproblemen, wenn diese verletzt werden.
- a-culfw: reichhaltige Unterstützung für SlowRf Protokolle, Portierung auf nicht ATmega Hardwareplattformen. Für HM wenig geeignet mangels Unterstützung für HM-Timing und HM-AES Signierung -> starke Anfälligkeit für FHEM Laufzeitunterschiede und auch kurze FHEM freezes
- tsculfw: verbesserte Stabilität, Verbesserungen bezüglich SlowRf Empfang und Senden. Für HM Unterstützung für HM-Timing und HM-AES Signierung -> verringerte Anfälligkeit für FHEM Laufzeitunterschiede und kurze FHEM freezes. Angepasste und neue FHEM-Module zur Nutzung mit der tsculfw Firmware. Frequenzoffset einstellbar.
[...]
Vor einem Test Rückweg vorbereiten. Backup FHEM. Alte Firmware nanoCULs als .hex bereit halten.

Wenn Deine nanoCULs eine abweichende Beschaltung aufweisen, board.h anpassen, compilieren und auf die nanoCULs flashen. Ansonsten TSnanoCUL.hex aus der zip auf die nanoCULs flashen.
Module durch Module aus zip austauschen. fhem.cfg anpassen. FHEM neu starten.

BESTEN DANK noansi für die gute Zusammenfassung. Irgendwo habe ich noch ein oder zwei nanoCULs rumliegen, die könnte ich testhalber flashen - der Tausch geht via Terminal-Modul recht gut.
Kann ich aculfw und tscuifw (jeweils ein nanoCUL) parallel betreiben? Aber wahrscheinlich ist das nicht sinnvoll.
Sende/Empfangsmodul (CC1101) ist nach Michael Heck angeschlossen - wie kann ich prüfen ob meine Beschaltung abweicht?

Ja, der ser2net-nanoCUL ist via LAN angebunden. WLAN ist Driss. Außer für die Geräte, die nicht anders können - oder nicht kritisch sind.

Bezgl. des Aufhängen des nanoCULs ist mir aufgefallen, dass es häufig den ser2net-nanoCUL betrifft. Der andere nanoCUL hängt direkt am FHEM-RasPi und wird beim FHEM Reboot mit neu initialisiert; der ser2net-nanoCUL nicht.
Zwischen der letzten neu-Initialisierung und dem letzten Aufhängen lagen weniger als 24 Stunden, Uptime seit dem liegt bei 3 Tagen und 5 Stunden. Ich beobachte.
Wenn sie hängen sagt uptime nichts mehr, die Kommunikation ist seitens FHEM nicht mehr möglich bis der CUL aus und wieder eingesteckt wird. Ansonsten wird das uptime-Reading nicht regelmässig aktualisiert.

Uih, und die ganzen Module tauschen bedeutet auch eine lange Liste an vom Update auszuschließende Dateien. Oder fhem die Rechte entziehen. Aber das ist ja kein Problem.

Vielen Dank nochmal für die Hilfe.

noansi · 08 März 2021, 00:19:37

Hallo yersinia,

ZitatKann ich aculfw und tscuifw (jeweils ein nanoCUL) parallel betreiben? Aber wahrscheinlich ist das nicht sinnvoll.

Du kannst tun, was Du nicht lassen kannst. Allerdings brauchst Du mich bei HM-Mischbetrieb gar nicht erst fragen, wenn etwas nicht funktioniert.

ZitatSende/Empfangsmodul (CC1101) ist nach Michael Heck angeschlossen - wie kann ich prüfen ob meine Beschaltung abweicht?

Passt wohl.
Die nanos müssen außerdem 16MHz Takt haben, damit es mit der hex harmoniert.

Zitatwird beim FHEM Reboot mit neu initialisiert; der ser2net-nanoCUL nicht.

Initialisiert wird er sicherlich, aber es behebt wohl nicht Dein "Absturz"-Problem. Ist die ser2net Verbindung nicht stabil? Stromversorgung ausreichend?

ZitatZwischen der letzten neu-Initialisierung und dem letzten Aufhängen lagen weniger als 24 Stunden, Uptime seit dem liegt bei 3 Tagen und 5 Stunden. Ich beobachte.
Wenn sie hängen sagt uptime nichts mehr,

uptime am CUL (die interessiert) musst Du manuell auslösen.

Gruß, Ansgar.