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

[noansi]

Hallo Jörg,

Hast du einen Tipp, wie ich die serial id ändern kann, dass die sich in /dev/serial/by-id nicht ins Gehege kommen?
Beide melden sich mit der selben ID an. Ich verwende jetzt /dev/ttyUSB0+1 aber das ist ja Port-abhängig - wäre schöner wenn sich jeder Nano mit einer eindeutigen ID anmeldet.

Das hängt an dem USB-Seriell Interface Chip auf den Nanos. Da müsstest Du schauen, ob die auch eine eindeutige Seriennummer haben.

Code Auswählen Erweitern

sudo lsusb -v
gibt unter iSerial auch die Seriennummer aus.
Eventuell gibt es ein Tool, mit dem die auch gesetzt werden kann?

Die beiden nanos sollen auf verbose 4 gestellt sein. Der virtuelle TC auf 2.

Wie ich aus Franks sehr hilfreichem Log schon sehen kann, cyclicMsgMissAdd ist gestorben. Da passiert nichts in der Richtung.
cyclicMsgDoShift macht danach im Vergleich zu einem realen TC auch direkt keinen Sinn. Außerdem sendet der TC exakt 20s nach der VD message seinen Status. Shift würde wohl irgendwann auch mal damit kollidieren.
Die HMLAN Uhr und die TC Uhr weichen voneinander ab. Die TC Uhr geht um etwa 25ms gegenüber HMLAN pro message nach.

Edit: die HMLAN Uhr tickt um 0.013% schneller, als Franks Server Uhr.
Die TC Uhr geht etwa 5,9ms pro message gegenüber Franks Server nach. Einen ähnlichen Wert habe ich bei mir auch mal bei einem TH-Sensor beobachtet.

Das entspräche einem cyclicMsgCorr von 6, wenn die HMLAN Uhr richtig geht (muss ich noch vergleichen).

Ich denke über einen Mix zwischen cyclicMsgDoShift (=1) und cyclicMsgCorr nach, weil nur mit cyclicMsgDoShift ein wenig Timerjitterkompensation möglich ist.

Aber erst mal schauen, wie die HMLAN Uhr tickt.

Gruß, Ansgar.

[noansi]

Hallo Jörg,

anbei eine neue Version zum Testen (nur Module geändert).

Die Erkenntnisse aus dem letzten Beitrag sind eingearbeitet inklusive cyclicMsgCorr mit Default 6.

cyclicMsgDoShift ist per Default auf 0, bleibt aber Spielwiese zum Durchtesten in längeren Messreihen für 0 und 1 für den TC.

Gruß, Ansgar.

[Adimarantis]

Hi Ansgar,

ok, habe jetzt erstmal wieder alle Attribute gelöscht und starte mit defaults.
Ich hatte vorher den Effekt , dass er wohl automatisch die CUL gewechselt hat (wohl nach massiven Misses), zumindest stand in beiden VD devices als IODev plötzlich die andere CUL. Was ist da das Kriterium? Wirklich gleichzeitig scheint er sie nicht zu verwenden
Danach war sicher 20 Minuten komplett Ruhe mit Misses (auf beiden VDs, beide liefen mit  S:1 A:0 O:3 ).
Nach dem Neustart mit neuen Modulen nimmt er wieder die erste und hat jetzt erstmal wieder misses (wie gesagt, mit deinen Defaults S:0, O:1) und gerade laufen beide VD sogar auf Fehler.
Hab jetzt beide VDs manuell auf die zweite CUL geschaltet und sie haben sich sofort wieder gefangen, wobei ich im Log "TSCUL_Send" und "TSCUL_XmitDlyHM" immer noch bei der ersten sehe. Die "Parse" Einträge sehe ich eigentlich immer bei beiden.

Jörg

[noansi]

Hallo Jörg,

Ich hatte vorher den Effekt , dass er wohl automatisch die CUL gewechselt hat (wohl nach massiven Misses), zumindest stand in beiden VD devices als IODev plötzlich die andere CUL. Was ist da das Kriterium? Wirklich gleichzeitig scheint er sie nicht zu verwenden

Das Kriterium sollte der RSSI beim jeweiligen VD device sein, da über die gesendet wird. Außerdem ggf. noch Überlastung der credits eines IOs.

Eventuell ist es schon ein Zeichen, wenn es über den "neuen" nano besser läuft.

Schick mal einen Log Auszug.

Gruß, Ansgar.

[Adimarantis]

Hi Ansgar,

nach dem HW-Fix an der ersten CUL lief es schon deutlich runder. Ich habe den Vergleich der beiden CUL auch mal genutzt um mit dem Frequenzoffset zu spielen (man sieht da ja recht schnell anhand des RSSI Vergleichs der gleichen Message, ob man was verbessert oder verschlechtert hat). Habe das jetzt von +25 auf +50 hochgedreht.
An üblicher Stelle nochmal ziemlich viel Logfile, das aber auch einige Spielereinen und evtl. auch kurzfristiges Abstecken einer CUL enthält.

Ich habe jetzt wieder auf Standard Szenario (eine CUL, TS_CUL verbose 0, S:0 O:1 ) zurückgedreht: Deutlich weniger misses und maximal einer in Folge, meistens bei Ventiländerungen (anbei das "grep miss"):

Code Auswählen Erweitern

2021.01.08 10:27:56.176 2: CUL_HM HMTC20_c1 11222001 mc:E7  tQ: 0.900  rQ: 0.000  dtu: 148510 ms  ueS: -23 ms  ueC: -21 ms  dti: 148506 ms  ieS: -18 ms  ieC: -16 ms  miss: 1
2021.01.08 10:29:40.187 2: CUL_HM HMTC20_c1 11222001 hI:125ms S:0 O:1 mc:E7->E8  dtp: 183507 ms  dtF: 183507 ms  dtcall: 8 ms  nv:n  miss: 1
2021.01.08 10:55:58.871 2: CUL_HM HMTC14_c1 11221401 mc:05  tQ: 0.905  rQ: 0.500  dtu: 164766 ms  ueS: 1 ms  ueC: 2 ms  dti: 164757 ms  ieS: 10 ms  ieC: 11 ms  miss: 1
2021.01.08 10:57:59.382 2: CUL_HM HMTC14_c1 11221401 hI:125ms S:0 O:1 mc:05->06  dtp: 136005 ms  dtF: 136005 ms  dtcall: 2 ms  nv:n  miss: 1
2021.01.08 11:10:37.182 2: CUL_HM HMTC14_c1 11221401 mc:0B  tQ: 0.889  rQ: 0.667  dtu: 142260 ms  ueS: -53 ms  ueC: -55 ms  dti: 142256 ms  ieS: -48 ms  ieC: -50 ms  miss: 1
2021.01.08 11:12:15.194 2: CUL_HM HMTC14_c1 11221401 hI:125ms S:0 O:1 mc:0B->0C  dtp: 177507 ms  dtF: 177506 ms  dtcall: 4 ms  nv:Y  miss: 1
2021.01.08 11:58:38.842 2: CUL_HM HMTC20_c1 11222001 mc:0B  tQ: 0.957  rQ: 0.500  dtu: 121507 ms  ueS: -66 ms  ueC: -68 ms  dti: 121505 ms  ieS: -63 ms  ieC: -65 ms  miss: 1
2021.01.08 12:01:00.112 2: CUL_HM HMTC20_c1 11222001 hI:125ms S:0 O:1 mc:0B->0C  dtp: 156756 ms  dtF: 156756 ms  dtcall: 10 ms  nv:Y  miss: 1
2021.01.08 12:31:52.040 2: CUL_HM HMTC14_c1 11221401 mc:2B  tQ: 0.932  rQ: 0.750  dtu: 128757 ms  ueS: 9 ms  ueC: -3 ms  dti: 128755 ms  ieS: 11 ms  ieC: 0 ms  miss: 1
2021.01.08 12:34:20.301 2: CUL_HM HMTC14_c1 11221401 hI:125ms S:0 O:1 mc:2B->2C  dtp: 164006 ms  dtF: 164006 ms  dtcall: 3 ms  nv:Y  miss: 1
2021.01.08 13:00:30.625 2: CUL_HM HMTC20_c1 11222001 mc:23  tQ: 0.957  rQ: 0.667  dtu: 159508 ms  ueS: -75 ms  ueC: -76 ms  dti: 159506 ms  ieS: -72 ms  ieC: -73 ms  miss: 1
2021.01.08 13:02:25.632 2: CUL_HM HMTC20_c1 11222001 hI:125ms S:0 O:1 mc:23->24  dtp: 130505 ms  dtF: 130504 ms  dtcall: 5 ms  nv:Y  miss: 1


Gruß,
Jörg

[Adimarantis]

Noch eine andere Frage:
An sich sollte doch ein hmPairForSec nötig sein um mit autocreate ein neues Device zu erzeugen und es zu pairen, oder?
Ich hatte jetzt schon zwei Mal einfach so ein neues Device im Setup. Einmal eine RT-DN und einmal einen Steckdosen Switch. Von beiden habe ich brav Modell, Firmware Version und XEQXXXXXX Nummer empfangen - und es sind bestimmt nicht meine.
Ich befürchte mein Nachbar versucht verzweifelt Homematic Devices zu pairen und meine CUL schnappt die ihm immer mal wieder weg. Ist da was falsch eingestellt oder ist das ein Bug?

Jörg

[noansi]

Hallo Jörg,

für den 1.4er (bisher nur den betrachtet) sehe ich, dass oft mal der eine und mal der andere nano den Ack bekommt.
So wirklich rund läuft der Ack Empfang bei beiden nanos noch nicht. Ist auch nicht abhängig davon, welcher zuvor gesendet hat. Und leider passiert es dann wohl auch, dass beide nicht empfangen.

An sich sollte doch ein hmPairForSec nötig sein um mit autocreate ein neues Device zu erzeugen und es zu pairen, oder?

Zum Pairen ja, aber Anlegen eines devices und Pairen sind zwei verschiedene Dinge.
Für das Anlegen reicht schon der Empfang einer Message mit passendem Message Typ von einem device bei aktivem Autocreate.
Ist ein gewolltes Verhalten und ändere ich auch nicht, wenn Martin es nicht ändert. Ohne hmPair... paired CUL_HM dann halt nicht.

Ich habe autocreate normalerweise disabled und aktivieres es nur, wenn ich irgend ein neues device anlernen möchte.

Gruß, Ansgar.

[noansi]

Hallo Jörg,

ich habe Dir mal eine spezial Version der Firmware für den nano gebaut.
Mit der wird die agcMaxDVGA Eunstellung vom SlowRF Modus für HM verwendet.
Wie Du mit ccconf sehen kannst, ist die bisher 1 und mit rfmode Homematic nicht änderbar.

Wenn Du diese Version flashest, dann kannst Du den nano temporär auf slowRf stellen, dort die gewünschte  Einstellung setzen und wieder nach Homeatic wechseln.
Dann da ein ccconf, um die Änderung zu prüfen.
Besser anschließend FHEM nochmal neu starten.

Schau mal, ob 0, 2 oder 3 eine Verbesserung bringen.

Gruß, Ansgar.

[Adimarantis]

Hallo Ansgar,

mein Setup läuft jetzt über 2 Tage produktiv (ohne die Firmware vom letzten Post). Frequenzoffset hab ich auf +70 wodurch der RSSI halbwegs in der Mitte ist.
Von den Einstellungen her läuft alles mit Standard ausser cyclicMsgDoShift=1

Code Auswählen Erweitern

rssi done:
    Device          receive         from             last   avg      min_max    count
    HM_VD_14        CUL_TS          HM_VD_14         -48.5  -50.0  -53.5< -47.5   397
    HM_VD_14        HM_VD_14        CUL_TS           -45.0  -46.3  -50.0< -45.0   397
    HM_VD_20        CUL_TS          HM_VD_20         -54.0  -54.1  -62.5< -53.5   374
    HM_VD_20        HM_VD_20        CUL_TS           -53.0  -53.6  -62.0< -52.0   374

Ich würde sagen die Anzahl der Fails hält sich in Grenzen. Alles in allem läuft es dafür, dass meine CC1101 wahrscheinlich ein ziemlicher Schrott ist, relativ gut.
Besten Danke für deine Hilfe und die geniale Firmware.

Jörg

Code Auswählen Erweitern

protoEvents send to devices done:
    name     :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM_VD_14 : done           |  -       | 403      |  -       #  -       | 6        |  -       |  -       
    HM_VD_20 : done           |  -       | 385      |  -       # 4        | 11       |  -       |  -       
=======================================================================================================
    sum      0                |0         |788       |0         #4         |17        |0         |0       

[noansi]

Hallo Jörg,

nochmal eine neue Version zum Testen.

Ich habe das Attribut cyclicMsgRecWinHalf entfernt (ist jetzt fest auf 125ms) und eine langsame dynamische Korrektur des Sendezeitpunkts ergänzt, was sich effektiv nur auf die Einstellung cyclicMsgDoShift=0 mit wenigen ms früherem Sendezeitpunkt äußern sollte (startet bei cyclicMsgDoShift=0 bei -5.4ms). Wie es sich entwickelt, ist am timing Reading mit c: x.x zu sehen.
Außerdem habe ich noch kleinere Bugs an Modulen behoben.

Bei der Firmware habe ich einen Ag Befehl ergänzt, mit dem die AGCCTRL2 Einstellung des Tranceivers für HM remanent verändert werden kann. Damit verbunden ist auch eine Änderung der EEPROM Belegung, was beim Flashen ein Reset aller CUL Einstellungen bewirkt. Also vor dem Flashen alle individuellen CUL Einstellungen notieren und anschließend FHEM neu starten.

Gruß, Ansgar.

[Adimarantis]

Hallo Ansgar,

hier das Resultat des produktiven Langzeittests über ca. 5 Tage:

Code Auswählen Erweitern

    name     :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM_VD_14 : done           |  -       | 1775     |  -       #  -       | 40       |  -       |  -       
    HM_VD_20 : done           |  -       | 1802     |  -       #  -       | 64       |  -       |  -       
=======================================================================================================
    sum      0                |0         |3577      |0         #0         |104       |0         |0     

TC 14: mc: 9 miss: 0 tQ: 0.977 rQ: 0.950 mSkp: 235 mNck: 40 dtu: 171267 ueS: -62 ueC: 1 dti: 171257 ieS: -51 ieC: 11 c: -1.8
cyclicMsgDoShift=1

TC 20: mc: 28 miss: 0 tQ: 0.964 rQ: 0.859 mSkp: 208 mNck: 64 dtu: 132513 ueS: 0 ueC: 0 dti: 132505 ieS: 8 ieC: 8 c: -2.2
cyclicMsgDoShift=1

    Device          receive         from             last   avg      min_max    count
    HM_VD_14        CUL_TS          HM_VD_14         -51.5  -48.8  -54.0< -41.5  1738
    HM_VD_14        HM_VD_14        CUL_TS           -47.0  -45.1  -55.0< -39.0  1738
    HM_VD_20        CUL_TS          HM_VD_20         -55.0  -54.2  -75.0< -52.5  1741
    HM_VD_20        HM_VD_20        CUL_TS           -54.0  -53.4  -74.0< -52.0  1741

Wenn du aus den Werten spontan einen Vorschlag hast irgendeine Einstellung zu ändern, kann ich das gerne mal probieren und wieder ein paar Tage so laufen lassen.

Wie anderweitig besprochen, blockiert mein ADS Modul ja derzeit FHEM hin- und wieder länger als notwendig. Das könnte durchaus einen Einfluss haben. Ich werde die neue Version dann demnächst in den Produktivtests nehmen - mal sehen ob das auch auf die ResndFail einen Einfluss hat. Außerdem muss ich wohl den 14 und 20 umwechseln. Der 14er hat irgendwie ein Problem auf Maximalposition (99) zu stellen und meldet dann immer 98. Ich brauche hier aber meistens volle Ventilöffnung. Scheint jetzt keinen wirklichen Einfluss auf die Funktion zu haben, führt aber dazu das ständig wieder ein "set_99%" ausgeführt wird (weil der Antrieb ja nicht da ist wo er hin soll). Der 20er verhält sich hier konsistenter (da brauche ich aber für meine Fußbodenheizung nur Position 25)

Gruß,
Jörg

[noansi]

Hallo Jörg,

Wenn du aus den Werten spontan einen Vorschlag hast irgendeine Einstellung zu ändern

Mit Deiner nano Empfangsproblematik würde mir ein besserer Angleich der RSSI Werte ins Auge springen. Die RSSI Werte vom 20er sind im Vergleich schlechter. Normalerweise wären das keine Problemwerte aber bei Dir macht das vielleicht schon den Unterschied.
Ich habe nochmal eine neue Variante bezüglich der Module angehangen, bei CUL wird damit der neue Ag Befehl per set unterstützt. Damit kannst Du per set hmAgcMaxDVGA bei den nanos doch mal an dem Parameter spielen (mit get ccconf siehst Du, ob es auch eingestellt wurde). Also statt dem default 1 mal 0 und 2 testen, ob das einen Unterschied macht.

Der 14er hat irgendwie ein Problem auf Maximalposition (99) zu stellen und meldet dann immer 98.

Was wird bei einem Stellwert von 98% zurück gemeldet?
Dann bräuchte ich nochmal ein nano verbose 4 Log vom Stellen auf 99%, "erfolgreich" sprich mit der raw Rückmeldung der 98%.
Das gleiche bitte auch vom 20er zum Vergleich, was da bei 99% Stellwert raw zurück gemeldet wird.

Wie anderweitig besprochen, blockiert mein ADS Modul ja derzeit FHEM hin- und wieder länger als notwendig.

Wahrscheinlich nicht nur das ADS Modul, da Du etwas mehr als 10% Skips hast. Sprich, die maximale, systembedingte Sendezeitpunktsverschiebung/Timeraufrufzeitpunkt hat entsprechend oft das Limit überschritten und es wurde deswegen nicht gesendet. 0% wird in FHEM nicht zu erreichen sein, aber schon konsequente Reduzierung nicht benötigter Events mit event-on-change-reading und event-on-update-reading bei allen FHEM devices ist ein erster Weg zur Besserung.

Gruß, Ansgar.

[Adimarantis]

Hi Ansgar,

hier schon mal die Logs. Da sollte jeweils eine Positionierung auf 99% drin sein (der 20er hat sich dann aber über meine Regelung wohl relativ schnell wieder auf 25% stellt, weiss also nicht ob da alles drin ist).
Ich tippe hier aber sowieso eher auf ein HW oder FW Problem im 14er VD und der Workaround mit Tausch der Antriebe ist ja auch einfach

Jörg

[noansi]

Hallo Jörg,

fahr den 14er mal auf 98%, wieder mit Log bitte.

Er meldet, dass er versucht zu öffnen, aber der Motor da oben blockiert. Müßtest Du auch beim VD in den Readings sehen können. Wenn's nur bis 98% geht, dann geht's halt nicht weiter und dann verlang es auch nicht von dem. 
Es gibt bei der 1.4er Firmware wohl auch noch einen F1 Bug, wenn man 100% versucht. Demnach endet ein Versuch auf 100% zu fahren auch schon mal in Zustand F1 im Display und nix fährt mehr, bis Reset mit Batterie raus und wieder rein, hab ich zumindest so gelesen.

Der 20er dagegen fährt nach seiner Rückmeldung ohne Murren auf die 99%.

Gruß, Ansgar.

PS: Möglicherweise fährt der 14er auch auf 99%, wenn Du ihn vorher ganz zu fährst. Dann wäre ein Bug in der Firmware, dass er mit der Zeit "Schritte" verliert.

[frank]

Wenn's nur bis 98% geht, dann geht's halt nicht weiter und dann verlang es auch nicht von dem.

das sollte ja normal kein problem sein, da der motor den stössel im vd eigentlich sehr viel weiter zurückziehen kann.
bei 100% berührt der stössel des vd ja gerade den stift am ventil.

ich würde mal eine neue adaptierungsfahrt durchführen.

bei meinen vd mit fw2.0 ist das auch manchmal zu beobachten.