Autor Thema: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38  (Gelesen 250848 mal)

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1272
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.
« Letzte Änderung: 04 März 2021, 21:36:31 von noansi »

Offline Adimarantis

  • Developer
  • Full Member
  • ****
  • Beiträge: 290
Hi Ansgar,

gibt's eine kurze Zusammenfassung der Änderungen?

Danke,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL
70+ Homematic/HMIP, Diverse 433Mhz Sensoren und Schalter
Module: 52_I2C_ADS1x1x (offiziell), 50_Signalbot, 50_SPI_MAX31865

Offline yersinia

  • Hero Member
  • *****
  • Beiträge: 1021
    • Cyanide & Happiness
Hallo zusammen,

gibt es auch eine Kurzübersicht (for dummies  ;D) 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.
viele Grüße, yersinia
----
FHEM 6.0 (SVN) on RPi 4B with RasPi OS Buster (perl 5.28.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@aculfw | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1272
Hallo yersinia,

Zitat
gibt es auch eine Kurzübersicht (for dummies  ;D) 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.

Zitat
eigentlich 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.

ser2netHoffentlich über LAN und nicht über WLAN.

Zitat
aber 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.

Zitat
Kann 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.
« Letzte Änderung: 07 März 2021, 08:17:02 von noansi »

Offline pte

  • Jr. Member
  • **
  • Beiträge: 78
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
Lichtenstein/Sa. grüßt den Rest der Welt

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1272
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.
« Letzte Änderung: 06 März 2021, 15:29:03 von noansi »

Offline pte

  • Jr. Member
  • **
  • Beiträge: 78
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
Lichtenstein/Sa. grüßt den Rest der Welt

Offline pte

  • Jr. Member
  • **
  • Beiträge: 78
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
Lichtenstein/Sa. grüßt den Rest der Welt

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1272
Hallo Peter,

Zitat
doch 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.

Offline pte

  • Jr. Member
  • **
  • Beiträge: 78
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
Lichtenstein/Sa. grüßt den Rest der Welt

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1272
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.

Offline pte

  • Jr. Member
  • **
  • Beiträge: 78
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
Lichtenstein/Sa. grüßt den Rest der Welt

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1272
Hallo Peter,

Zitat
Es 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.

Offline yersinia

  • Hero Member
  • *****
  • Beiträge: 1021
    • Cyanide & Happiness
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. :)
viele Grüße, yersinia
----
FHEM 6.0 (SVN) on RPi 4B with RasPi OS Buster (perl 5.28.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@aculfw | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1272
Hallo yersinia,

Zitat
Kann 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.

Zitat
Sende/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.

Zitat
wird 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?

Zitat
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,
uptime am CUL (die interessiert) musst Du manuell auslösen.

Gruß, Ansgar.
« Letzte Änderung: 08 März 2021, 00:24:58 von noansi »