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

Offline noansi

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

Zitat
Ich 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.
« Letzte Änderung: 22 März 2021, 19:29:04 von noansi »
Informativ Informativ x 1 Liste anzeigen

Offline pte

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

Offline noansi

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

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

Zitat
Kann man daraus noch etwas schlussfolgern?
Nein. Setzt Du die 3 mal so kurz hintereinander ab?

Gruß, Ansgar.


Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1119
Hallo Testwillige,

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

TC statusRequest.

Gruß, Ansgar.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1119
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.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1119
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.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline pte

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

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1119
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.
« Letzte Änderung: 05 April 2021, 17:49:42 von noansi »

Offline pte

  • Jr. Member
  • **
  • Beiträge: 78
Ok. Danke.
Dann mal noch schöne Ostern.

Gruß Peter
Lichtenstein/Sa. grüßt den Rest der Welt

Offline pte

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

Offline noansi

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

Offline riker1

  • Sr. Member
  • ****
  • Beiträge: 858
Hi,

eine Frage.

das Reading CommandAccepted
wird im filelog nicht geloggt und erzeugt keinen Event?

Habe ich da was übersehen?

Attribute ist gesetzt.

event-on-update-reading .*

Danke VG T







FHEM 5.9 Ubuntu, FHEM 5.9 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1119
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.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline riker1

  • Sr. Member
  • ****
  • Beiträge: 858
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

FHEM 5.9 Ubuntu, FHEM 5.9 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

Offline yersinia

  • Sr. Member
  • ****
  • Beiträge: 979
    • Cyanide & Happiness
Hier mal ein Feedback zu dem Thema Optiboot und alter Bootloader:
ok, 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:
44 19:53:33Der 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). 8)
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