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

OiledAmoeba · 01 Dezember 2017, 01:08:14

Scheinbar war's der Speicher. Er springt jetzt nicht mehr ständig weg. Aber er liest jetzt fleißig meine verbliebenen FHT's (als "Raumtemperatursensor" noch halbwegs brauchbar) und lässt sich nicht umstellen. HomeMatic not supported, wrong Firmware?

Die verschiedenen gets sehen so aus:

Code Auswählen

TSCUL ITSndFreq => 433.920MHz 
TSCUL SlowRFSndFreq => 868.300MHz
get TSCUL assignIDs needs rfmode HomeMaticTSCUL ccconf => freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s 
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0 
CCAmode:1 csRelThr:10dB csAbsThr:4dB 
TSCUL cmds =>  A B C E F G J K M N R U V W X Y Z e i l m t x 
TSCUL credit10ms => 1592
SlowRF TSCUL Receive Statistic: 

freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s 
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0 
CCAmode:1 csRelThr:10dB csAbsThr:4dB 
TSCUL fhtbuf => No answer

Weiter bin ich nicht gekommen.
get fhtbuf hat ihn abgeschossen. (obwohl er im SlowRF war)
set reload führte dazu, das er wieder toggelte und Sonderzeichen ausspuckte.
Nachdem ich ihn aus- und wieder eingesteckt hatte, fing er gleich wieder an zu toggeln.

Dann habe ich ihn (ohne die DEF zu ändern!) auf dummy=1, rfmode=HomeMatic gesetzt (er hat ja auf get cmds mit A geantwortet) und anschließend das Attribut dummy wieder gelöscht. Wie bin ich auf Dummy gekommen? Eigentlich wollte ich ihn abschalten, weil ich ihn auf a-culfw zurückflashen wollte..
Und nu? Er funkt fein im HomeMatic-Modus.
Verbose hab ich wieder auf 2 runter, nicht, dass da morgen die Festplatte voll ist

Morgen nach er Arbeit probiere ich dann sein Verhalten bei AES.

Also bleibe ich erst mal bei "Scheinbar war's der Speicher".

Ach, fast vergessen: Den nanoCUL habe ich nicht selbst gebaut (ich hatte ihn aus der Bucht, glaub ich) und dank meiner alten Befestigung mit Malerkrepp sind durch den Schrumpfschlauch nur noch die LED's zu erkennen... Vielleicht schaffe ich es mal, ihn zu reinigen. Dann kann ich sicher genauere Info's geben.

Bytechanger · 01 Dezember 2017, 09:15:22

HAllo noansi,

vielen Dank. Aber ich sehe keine Anlage in Deinem Post.

Greets

Byte

OiledAmoeba · 01 Dezember 2017, 20:15:21

Hmpf, da bin ich wieder. Never touch, oder so...
Wollte gerade den Fensterkontakt anlernen, siehe da, der TSCUL sendet nicht mehr, trotz Condition OK. Empfangen hat er hm noch fleißig.
Tja, fhem neu gestartet (vorher attr global motd none und save):

Code Auswählen

2017.12.01 19:43:36.767 3 : Setting TSCUL serial parameters to 38400,8,N,1
2017.12.01 19:43:38.337 0 : TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.12.01 19:43:38.339 1 : TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.12.01 19:43:38.850 3 : TSCUL: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2017.12.01 19:43:39.530 1 : TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.12.01 19:43:39.978 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:43:40.715 TSCUL TSCUL cond: non-HM
2017-12-01 19:43:40.715 TSCUL TSCUL Xmit-Events: disconnected:2 non-HM:1 
2017-12-01 19:43:40.715 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:43:41.600 CUL_HM VCCU TSCUL:non-HM,
2017-12-01 19:43:42.690 TSCUL TSCUL Initialized
2017.12.01 19:43:42.795 1 : /dev/ttyU0 disconnected, waiting to reappear TSCUL
2017-12-01 19:43:43.346 TSCUL TSCUL DISCONNECTED
2017.12.01 19:43:43.346 2 : TSCUL_condUpdateHM: TSCUL new condition disconnected
2017-12-01 19:43:43.931 TSCUL TSCUL cond: disconnected
2017-12-01 19:43:43.931 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:1 
2017-12-01 19:43:43.931 TSCUL TSCUL prot_disconnected: last
2017-12-01 19:43:44.522 CUL_HM VCCU TSCUL:disconnected,
2017-12-01 19:43:45.006 TSCUL TSCUL disconnected

Code Auswählen

Messages collected while initializing FHEM:
configfile: ASKSIN not supported
ASKSIN not supported

Autosave deactivated

Was mich irritiert: TSCUL External Reset Restart detected: C_RE - muss das so?

Nächste Schritte: (Log darunter)
attr TSCUL dummy 1
set TSCUL reopen
im Log tauchen nun T-Protokolle auf, also attr TSCUL rfmode HomeMatic. Jetzt werden A-Protokolle empfangen.
Leider kann er noch immer nicht senden, da ich die hmId nicht setzen kann: "ASKSIN not supported". Kein Wunder, während des Init war es ein Dummy. Damit "Nocmdsfordummies", also auch kein A...

Hier das Log:

Code Auswählen

2017.12.01 19:56:31.941 3 : Setting TSCUL serial parameters to 38400,8,N,1
2017.12.01 19:56:33.518 0 : TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.12.01 19:56:33.523 1 : TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.12.01 19:56:34.190 3 : TSCUL: Possible commands: Nocmdsfordummies
2017.12.01 19:56:34.193 1 : TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.12.01 19:56:34.198 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:56:35.102 TSCUL TSCUL cond: non-HM
2017-12-01 19:56:35.102 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:4 
2017-12-01 19:56:35.102 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:56:35.123 CUL_HM VCCU TSCUL:non-HM,
2017-12-01 19:56:35.976 TSCUL TSCUL Initialized
2017.12.01 19:56:40.446 3 : TSCUL: Possible commands: Nocmdsfordummies
2017.12.01 19:56:40.793 1 : TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.12.01 19:56:40.811 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:56:41.802 TSCUL TSCUL cond: non-HM
2017-12-01 19:56:41.802 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:5 
2017-12-01 19:56:41.802 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:56:41.815 CUL_HM VCCU TSCUL:non-HM,
2017-12-01 19:56:42.034 TSCUL TSCUL Initialized
2017.12.01 19:56:42.036 1 : /dev/ttyU0 reappeared (TSCUL)
2017-12-01 19:56:42.475 TSCUL TSCUL CONNECTED
2017.12.01 19:56:42.835 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:56:43.450 TSCUL TSCUL cond: non-HM
2017-12-01 19:56:43.450 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:6 
2017-12-01 19:56:43.450 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:56:43.463 CUL_HM VCCU TSCUL:non-HM,
2017.12.01 19:56:43.464 4 : TSCUL_Parse: TSCUL 007482 A F702 00009160 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2017-12-01 19:56:59.169 TSCUL TSCUL UNKNOWNCODE T071F002200
2017.12.01 19:56:59.171 2 : TSCUL_Parse: TSCUL unknown message T071F0022002017-12-01 19:56:59.795 TSCUL TSCUL UNKNOWNCODE T4135002200
2017.12.01 19:56:59.797 2 : TSCUL_Parse: TSCUL unknown message T41350022002017-12-01 19:57:00.218 ROOMMATE rr_Florian durTimerAbsence_cr: 53
2017.12.01 19:57:01.199 2 : TSCUL_condUpdateHM: TSCUL new condition init
2017.12.01 19:57:01.202 1 : PERL WARNING: Use of uninitialized value in numeric ge (>=) at ./FHEM/00_TSCUL.pm line 4579.
2017-12-01 19:57:01.645 TSCUL TSCUL cond: init
2017-12-01 19:57:01.645 TSCUL TSCUL Xmit-Events: init:1 disconnected:3 non-HM:6 
2017-12-01 19:57:01.645 TSCUL TSCUL prot_init: last
2017-12-01 19:57:02.072 CUL_HM VCCU TSCUL:init,
2017.12.01 19:57:02.072 2 : Switched TSCUL rfmode to HomeMatic
2017-12-01 19:57:02.514 Global global ATTR TSCUL rfmode HomeMatic
2017.12.01 19:57:03.227 4 : TSCUL_SendPingHM TSCUL ApC0 send. Throttle continue
2017.12.01 19:57:03.821 4 : TSCUL_ParseTsHM: TSCUL Xmit release ping received, XmitOpen ->2 : 028437 A F702 00029724 00 01 C0 _ping
2017.12.01 19:57:04.026 4 : TSCUL_SendPingHM TSCUL ApC0 send. Throttle continue
2017.12.01 19:57:04.045 4 : TSCUL_ParseTsHM: TSCUL Xmit release ping received, XmitOpen ->1 : 028710 A F702 00030520 00 01 C0 _ping
2017.12.01 19:57:09.340 4 : TSCUL_Parse: TSCUL 033995 A F702 00035528 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2017.12.01 19:57:31.383 1 : PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/00_TSCUL.pm line 1544.
2017.12.01 19:57:31.455 4 : TSCUL_Parse: TSCUL 056041 A F701 00057844 00 0F A0 8610 51C812 000000 0AB0F00C0700 -82dB -82

Irgendwas klemmt da noch...

EDIT: Nach deleteattr TSCUL dummy sendet er auch wieder. Trotzdem finde ich den Weg, ihn zum laufen zu bringen etwas holprig...

noansi · 01 Dezember 2017, 21:11:26

Hallo Florian,

was kommt auf ein "get unusedstack" ?

Zitatget fhtbuf hat ihn abgeschossen.

FHT80b ist nicht in der Firmware konfiguriert. Daher wird auf T03 (was damit an den nano gesendet wird) nicht mit der erwarteten Antwort geantwortet, sondern das als Disconnected interpretiert. Da kann ich wohl den Match noch modifizieren.

Du kannst mal get raw T03 eingeben. Da müsste dann unknow command gefolgt von der Befehlsliste kommen.

Kannst Du verbose mal auf 5 stellen. Vielleicht ist dann zu sehen, was das Verschlucken auslöst.

Gruß, Ansgar.

noansi · 01 Dezember 2017, 21:32:52

Hallo Florian,

ZitatWas mich irritiert: TSCUL External Reset Restart detected: C_RE - muss das so?

Es ist ein nano Neustart aufgetreten sagt die Meldung. Eigentlich sollte External Reset dann die Reset Ursache sein. Macht der nano das eventuell, wenn die Baudrate umgestellt wird?
Der Watchdog hat jedenfalls nicht zugeschlagen.

Gruß, Ansgar.

noansi · 01 Dezember 2017, 21:33:37

Hallo Byte,

hängt aber dran. Warst Du nicht eingeloggt?

Gruß, Ansgar.

Bytechanger · 02 Dezember 2017, 09:55:43

Oops, stimmt.

Habs kopiert, FHEM neu gestartet. Leider ohne Erfolg.
Wie lange braucht es, bis es sich durchsetzt?
Ich habe beim CUL die beiden neuen Sensoren und einen Rauchmelder in den IDs, obwohl alle erstmal dem HMLAN zugewiesen sind!

Greets

Byte

noansi · 02 Dezember 2017, 10:30:17

Hallo Byte,

ZitatWie lange braucht es, bis es sich durchsetzt?

Beim Senden ans device sollte der Wechsel stattfinden. (grob gesagt. es ist noch komplizierter)

Zitatobwohl alle erstmal dem HMLAN zugewiesen sind

Was steht bei den devices oben in den Internals jeweils bei IODev?

Gruß, Ansgar.

Bytechanger · 02 Dezember 2017, 10:42:34

OK,

also habe ich ein getConfig gesendet und zusätzlich bei den "passiven" Fensterkontakten mal den Sabotagealarm durch Öffnen des Gehäuses ausgelöst.
Damit sind die Devices nun alle beim HMLAN, was auch die Eintragungen jetzt in den INTERNALS zeigen.

Greets

Byte

(Sabotagealarm, da ich die Fensterkontakte als "Wassersensoren" missbraucht habe und an den Reedkontakt Kabel angelötet habe; damit war ein einfaches Öffnen/Schließen jetzt auf die Schnelle nicht möglich)

noansi · 02 Dezember 2017, 10:49:21

Hallo Byte,

welche Firmware Version hast Du jetzt auf dem nano drauf?

Wenn es die VTS 0.19 ist, was sagt get unusedstack bei dem nano?

Oder kannst Du mit der VTS 0.19 die Probleme von OiledAmoeba nachvollziehen?

Gruß, Ansgar.

Bytechanger · 02 Dezember 2017, 10:52:45

Also ich habe einen CUL V3.4.
Ich dachte, ich hätte V0.19 drauf, wenn ich aber in die INTERNALS schaue, sehe ich

VERSION
VTS 0.18 CUL868
VERSION_HW CUL_V3.4
VERSION_TS yes AES ChTblSize:220

Readings:
version VTS 0.10 CUL868

CUL0 unusedstack => No answer

noansi · 02 Dezember 2017, 11:03:39

Hallo Byte,

ZitatAlso ich habe einen CUL V3.4.

Ja stimmt, dann vergiss es, kein sinnvoller Vergleich zum nano.

ZitatVTS 0.18 CUL868

ZitatCUL0 unusedstack => No answer

VTS 0.18 kann das noch nicht.

ZitatReadings:
version VTS 0.10 CUL868

kannst Du über get version aktualisieren.

Gruß, Ansgar.

Bytechanger · 02 Dezember 2017, 12:52:48

Sorry, ging davon aus, dass V0.19 drauf ist.

Nun ergibt
CUL0 unusedstack => 439

Code Auswählen

Messages collected while initializing FHEM:
configfile: ASKSIN not supported
ASKSIN not supported

hatte ich auch schon mal gesehen.
Hatte vermutet, dass ich nicht alle .pm Dateien aktualisiert hatte.

Byte

OiledAmoeba · 02 Dezember 2017, 23:46:30

Moin,
bin leider jetzt erst wieder am PC. Hatte heute morgen mal einen "Syncverlust" und meine Versuche der Rettung mit Verbose 5 mitgeschrieben.
Dabei habe ich ihn mindestens einmal stromlos gemacht, weiß leider nicht mehr, wann das genau war. Da das Log wieder mit Steuerzeichen gefüllt wurde, die ich hier nicht reinkopieren kann, habe ich das als Datei rangehängt.

Derzeit behelfe ich mir mit einem Notify, denn wenn sich die Verbindung verabschiedet hat, geht er nicht sofort auf disconnected, worauf man triggern könnte, sondern hm meldet IOErr:

Code Auswählen

define n_TSCULreset notify hm..*:IOErr|cr:reset \
{fhem ("attr TSCUL dummy 1")};; {fhem("sleep 2;; set TSCUL reopen")};; {fhem("sleep 7;; attr TSCUL rfmode SlowRF")};; {fhem("sleep 8;; attr TSCUL rfmode HomeMatic")};; {fhem("sleep 10;; deleteattr TSCUL dummy")};; {fhem("set cr ok")}

hm..* mit zwei Punkten, damit das Notify nicht hm und die Heizungen verwechselt (die alle mit hm. beginnen). Kann ich dann automatisiert über IOErr oder manuell über den dummy cr auslösen und klappt erstmal. Natürlich nicht die Lösung, denn laut Wiki soll bei 1% auch IOErr kommen, also seeeehr unsauber, mein Lösungsweg...

klausw · 03 Dezember 2017, 00:04:01

Hallo Ansgar,

Zitat von: noansi am 02 Dezember 2017, 10:49:21
Oder kannst Du mit der VTS 0.19 die Probleme von OiledAmoeba nachvollziehen?

Die Frage galt zwar nicht mir, aber ich habe die gleichen Probleme wie OiledAmoeba mit dem NanoCUL VTS 0.19 und VTS 0.18

Das Logfile füllt sich mit

Code Auswählen

TSCUL_Parse: TSCUL External Reset Restart detected: C_RE

Im Testsystem lief alles (da habe ich aber nur nen Dimmer und Rauchmelder dringehabt. Alles Ohne AES)
Beim aufspielen auf das Produktivsystem lief nix mehr.
Derzeit kann ich nicht testen, da ich nicht mehr vor Ort bin. Ich bin erstmal wieder auf die TSCUL_fwcode_00_10_FHEM_Modules_00_11 gegangen.