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

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

Lowbird

Hallo Ansgar, Joachim und Martin.

Also, ich habe es wie versprochen auch getestet. Dateien ausgetauscht, altes Device gelöscht, Save Config, shutdown restart, und pairforsec 60.
Dann Klingelsensor resettet und einmal angelernt.

Nun bekomme ich zur Abwechslung ein IOerr

Sodele, das List des Sensors:

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     1
   NAME       HM_398BE6
   NOTIFYDEV  global
   NR         152
   STATE      IOerr
   TYPE       CUL_HM
   lastMsg    No:01 - t:00 s:398BE6 d:000000 1000DC4D45513036353637383740010101
   nanoCUL_MSGCNT 1
   nanoCUL_RAWMSG A1A018400398BE60000001000DC4D45513036353637383740010101::-68.5:nanoCUL
   nanoCUL_RSSI -68.5
   nanoCUL_TIME 2016-08-09 20:00:32
   protCmdDel 4
   protIOerr  1 last_at:2016-08-09 20:01:31
   protLastRcv 2016-08-09 20:00:32
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL lst:-68.5 avg:-68.5 min:-68.5 cnt:1 max:-68.5
   Readings:
     2016-08-09 20:00:32   D-firmware      1.0
     2016-08-09 20:00:32   D-serialNr      MEQ0656787
     2016-08-09 20:00:32   R-pairCentral   set_0x2703CC
     2016-08-09 20:01:31   state           IOerr
   Helper:
     HM_CMDNR   40
     Supp_Pair_Rep 1
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +398BE6,00,00,00
       nextSend   1470765632.38789
       prefIO
       rxt        0
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        01
       Io:
         nanoCUL    -66.5
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -68.5
         cnt        1
         lst        -68.5
         max        -68.5
         min        -68.5
     Shadowreg:
       RegL_00.    02:01 0A:27 0B:03 0C:CC
Attributes:
   IODev      nanoCUL
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton



und das Log:

2016.08.09 20:00:32.260 2: CUL_HM Unknown device HM_398BE6 is now defined
2016.08.09 20:00:32.262 2: autocreate: define HM_398BE6 CUL_HM 398BE6
2016.08.09 20:00:32.264 2: autocreate: define FileLog_HM_398BE6 FileLog ./log/HM_398BE6-%Y.log HM_398BE6
2016.08.09 20:00:32.300 3: CUL_HM pair: HM_398BE6 pushButton, model HM-Sen-DB-PCB serialNr
2016.08.09 20:01:39.534 2: CUL_Parse: nanoCUL new condition Warning-HighLoad
2016.08.09 20:01:39.538 4: CUL_Parse: nanoCUL  496060 A FFB1 00173992 00 14 03 A45F 33C508 2703CC 827237006E9D051808DB01 -73.5
2016.08.09 20:01:39.551 4: CUL_send:  nanoCUL                      Aw 0B 0A 03 8002 2703CC 33C508 00
2016.08.09 20:01:39.551 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:87 tgtdly:120 toms:99
2016.08.09 20:01:39.669 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:01:39.669 4: CUL_Parse: nanoCUL  496202 A FFB3 00174112 00 0A 03 8002 2703CC 33C508 00 -138
2016.08.09 20:01:47.292 4: CUL_Parse: nanoCUL  503820 A FFA1 00181760 00 14 42 845E 33C508 000000 82723C006115047A08E702 -73
2016.08.09 20:01:47.552 4: CUL_Parse: nanoCUL  504080 A FFA1 00182016 00 14 04 A45F 33C508 2703CC 82723C006115047A08E702 -74
2016.08.09 20:01:47.565 4: CUL_send:  nanoCUL                      Aw 0B 0A 04 8002 2703CC 33C508 00
2016.08.09 20:01:47.566 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:89 tgtdly:120 toms:99
2016.08.09 20:01:47.685 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:01:47.685 4: CUL_Parse: nanoCUL  504218 A FFA3 00182136 00 0A 04 8002 2703CC 33C508 00 -138
2016.08.09 20:01:56.532 4: CUL_Parse: nanoCUL  513060 A FFA1 00191008 00 14 05 A45F 33C508 2703CC 827243006F89051A08E203 -74.5
2016.08.09 20:01:56.545 4: CUL_send:  nanoCUL                    Aa 5D53 0A 05 8002 2703CC 33C508 00
2016.08.09 20:01:56.545 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:91 tgtdly:120 toms:102
2016.08.09 20:01:56.669 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:01:56.669 4: CUL_Parse: nanoCUL  513202 A FFA3 00191128 00 0A 05 8002 2703CC 33C508 00 -138
2016.08.09 20:02:04.313 4: CUL_Parse: nanoCUL  520840 A FFA1 00198792 00 14 06 A45F 33C508 2703CC 82724800647604A608DF03 -73.5
2016.08.09 20:02:04.326 4: CUL_send:  nanoCUL                      Aw 0B 0A 06 8002 2703CC 33C508 00
2016.08.09 20:02:04.326 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:88 tgtdly:120 toms:99
2016.08.09 20:02:04.445 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:02:04.446 4: CUL_Parse: nanoCUL  520979 A FFA3 00198912 00 0A 06 8002 2703CC 33C508 00 -138



Irgendwie habe ich das Gefühl, das pairing ist nicht beendet worden. Was mir auch neu ist, ist diese Meldung : nanoCUL new condition Warning-HighLoad. Glaube kaum, dass er bei meinen 14 Devices an die Grenze der 1% Regel kommt.  :o
FHEM 5.7
FritzBox 7490
Vu+ Duo2
IP-Cam Instar 6012HD
IP-Cam Instar 5907HD

MadMax-FHEM

Hi Chris,

highload hatte ich nach dem shutdown restart auch...

Hab mal durchgebootet (dann wird die Load zurück gesetzt) und danach gings...

Mit dem Zustand highload hab ichs gar nicht erst versucht...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Lowbird

#197
So Problem gefunden und eliminiert. Meine HUE-Brigde schien zu hängen. Auch mehrfaches rebooten half nicht. Also die Bridge von Hand resettet, neu gepairt, reboot gemacht.
Danach gewartet bis highload vorbei war und dann mal nach dem Klingelsensor geschaut.

Der war ja nun schon "angelernt", hatte aber bei STATE komischerweise jetzt "? ? ?" drei Fragezeichen.

Dann mal die Klingel gedrückt und nun geht er.

Hier mal das List:

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     11
   NAME       HM_398BE6
   NOTIFYDEV  global
   NR         200
   STATE      HM_398BE6 Short
   TYPE       CUL_HM
   lastMsg    No:05 - t:40 s:398BE6 d:2703CC 0103
   nanoCUL_MSGCNT 11
   nanoCUL_RAWMSG A0B05A240398BE62703CC0103::-59.5:nanoCUL
   nanoCUL_RSSI -59.5
   nanoCUL_TIME 2016-08-09 20:58:44
   protLastRcv 2016-08-09 20:58:44
   protSnd    10 last_at:2016-08-09 20:58:44
   protState  CMDs_done
   rssi_at_nanoCUL max:-59.5 lst:-59.5 min:-85.5 avg:-75.38 cnt:13
   Readings:
     2016-08-09 20:50:19   CommandAccepted yes
     2016-08-09 20:52:49   D-firmware      1.0
     2016-08-09 20:52:49   D-serialNr      MEQ0656787
     2016-08-09 20:52:50   PairedTo        0x2703CC
     2016-08-09 20:52:50   R-pairCentral   0x2703CC
     2016-08-09 20:52:50   R-sign          off
     2016-08-09 20:52:50   RegL_00.          02:01 05:00 0A:27 0B:03 0C:CC 14:06 18:00 00:00
     2016-08-09 20:52:50   RegL_01.          04:10 08:00 30:06 00:00
     2016-08-09 20:58:44   battery         ok
     2016-08-09 20:58:44   state           HM_398BE6 Short
     2016-08-09 20:58:44   trigDst_2703CC  noConfig
     2016-08-09 20:58:44   trigger         Short_3
     2016-08-09 20:58:44   trigger_cnt     3
   Helper:
     BNO        3
     BNOCNT     1
     HM_CMDNR   5
     cSnd       012703CC398BE601040000000001,012703CC398BE60103
     mId        00DC
     peerIDsRaw ,00000000
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       AunknCnt   1
       LRcTm      1153736
       LastRecTyp 40
       dwoCCAAa   120
       dwoCCAAw   120
       lastSend   1470769124.26695
       lastSendtgd 120
       newChn     +398BE6,00,00,00
       nextSend   1470769124.26695
       nextSendMcnt 05
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        05
       Io:
         nanoCUL    -57.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         nanoCUL
       flg        A
       ts         1470769124.16285
       ack:
         HASH(0x68739f0)
         0580022703CC398BE600
     Rssi:
       At_nanocul:
         avg        -75.3846153846154
         cnt        13
         lst        -59.5
         max        -59.5
         min        -85.5
     Shadowreg:
Attributes:
   IODev      nanoCUL
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   peerIDs    00000000,
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton


Ansgar, ich werde ihn morgen eventuell nochmal unpairen und neu pairen, wenn du das Log auch noch benötigst. Jetzt muss ich erstmal in die Falle, war ja wie gesagt seit Donnerstag auf Dienstreise.
Danke euch allen, allen voran Ansgar, dass soviel Zeit und Mühe investiert wurde, um dieses "bockige" Device mit einem CUL zur Zusammenarbeit zu bewegen.


LG Chris
FHEM 5.7
FritzBox 7490
Vu+ Duo2
IP-Cam Instar 6012HD
IP-Cam Instar 5907HD

noansi

#198
Hallo Chris,

das mit Warning-HighLoad hängt mit den credits zusammen und auch damit, dass ich mir das mit der 1% Regel mal durchgelesen habe.

Danach muss es eine 1%/h Sendezeitbeschränkung im Gerät geben und es darf keinen Befehl geben, um die Sendezeitbeschränkung im Gerät zurück zu setzen.
Blöderweise gibt es aber den Reboot Befehl, der leider auch die credits zurück setzt. Und volle "Aufladung" geht somit nicht.

Wenn Du also neu startest und auch den nanoCUL frisch mit Strom versorgt hast (oder auch ein Reset mit in den CUL Init integriert hast), dann geht erst mal nicht viel, bis die credits genügend "nachgeladen"sind. sprich, Du musst warten. 10% ist die Grenze für Warning-HighLoad und somit beim CUL Neustart normal. Immerhin kommt jetzt die Warnung und CUL_HM wird gebremst, CUL und das FHEM-System mit zwecklosen Sendbefehlen zu überfordern.

Wenn Du beim Start schon einiges an andere devices sendest, dann kann es auch sein, dass Du so das Sendelimit erreicht hast.

Bei den HM devices sollte autoReadReg auf 5_readMissing eingestellt sein, damit nicht unnötig Rgisterwerte vom device abgerufen werden und Du solltest HMinfo mit Archivierung nutzen, also so was

#################
# Homematic Info
#################

define HM_Info HMinfo
attr HM_Info autoArchive 1
attr HM_Info autoUpdate 08:00
attr HM_Info configDir /opt/fhem
attr HM_Info configFilename HM_Info_Save.dat
attr HM_Info room Receiver
attr HM_Info sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
attr HM_Info sumStatus battery,sabotageError,powerError,motor

in Deiner fhem.cfg stehen haben. Dann werden die schon gelesenen Registerwerte in HM_Info_Save.dat gespeichert und beim nächste fhem start wieder gelesen, statt sie vom device anzufordern und damit credits zu verschwenden.

Es wurde so auch in Deinem Log Auszug nichts an das device gesendet, nachdem Dein pairing request empfangen wurde.
Also warte einfach und probier es nochmal, wenn cond Warning-HighLoad nach cond ok wechselt.

Gruß, Ansgar.

noansi

Hallo Chris,

ZitatDanke euch allen, allen voran Ansgar, dass soviel Zeit und Mühe investiert wurde, um dieses "bockige" Device mit einem CUL zur Zusammenarbeit zu bewegen.

Bitte, bitte. Allerdings sind wir damit nur bei einer Funktion mit meiner speziellen Version der Dateien und der Firmware und dem Grund für das Problem auf die Spur gekommen.
Ständig die Aktualisierungen von FHEM darin einzupflegen kann ich leider nicht dienstleisten. Ich hoffe Martin schafft mit diesen Hinweisen das Pairing und getConfig seiner 10_CUL_HM.pm mit CUL zu verbessern und das unabhängig von 00_CUL.pm und Firmware.

Sonst ist mit dem nächsten Update von FHEM wieder Schluss mit "Funktion" beim Anlernen des Klingelsensors mit CUL.

Gruß, Ansgar.

noansi

#200
Hallo Testwillige,

hier mein letzter Stand nochmal gesammelt (keine Änderungen an der Firmware).

Im perl Timing Code habe ich noch Änderungen bezüglich Wiederholungstiming vorgenomen.
Zusätzlich Formatierungsanpassungen, damit mit z.B. Notepad++ besser am Code gearbeitet werden kann.

Es gilt für den perl Code wie gehabt:
Erst Backup der vorhandenen Dateien und dann Austausch. Die Codebasis ist nicht der neueste Stand.

EDIT: Anhang gelöscht. Hier https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979 ist der neue Stand.

Gruß, Ansgar.

davedeluxe

Ich bekomme folgenden Fehler:
Compilation failed in require at ./FHEM/10_CUL_HM.pm line 10, <$fh> line 528.
BEGIN failed--compilation aborted at ./FHEM/10_CUL_HM.pm line 10, <$fh> line 52$

noansi

Hallo Dave,

das Problem kann ich leider nicht am Code nachvollziehen.

Aber eventuell hilft Dir das https://forum.fhem.de/index.php/topic,21924.msg153781.html#msg153781 "Thema: gelöst: Fehler FHEM 10_CUL_HM - Compilation failed" weiter.

Gruß, Ansgar.

davedeluxe

Hey,

wollte meinen Post grade entfernen oder updaten.
Meine Test-Fheminstallation ist grade  am spinnen und das war wohl der Grund für die Fehler.
Sorry fürs voreilige Posten, ich werds morgen nochmal in Ruhe testen und bin mir sicher es läuft - so wie immer ;)

Grüße Dave

dog_martin

Ich versuche mich gerade als Tester; nicht zuletzt um meine Displays benutzen zu können.

Die Module habe ich getauscht und die CUL_V3.hex aus dem culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip geflasht.
Neustart und jetzt kann der CUL nicht mehr initialisiert werden...

Frage:
Kann ich die bereits enthaltene CUL-V3.hex aus dem culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip nehmen oder muss ich den Sourcecode compilieren???

Vielen Dank für einen kurzen Tipp!

noansi

Hallo Dog,

ZitatKann ich die bereits enthaltene CUL-V3.hex aus dem culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip nehmen oder muss ich den Sourcecode compilieren???

Wenn Deine CUL Hardware ein CUL V3 ist, dann kannst Du das Hex aus der Zip nehmen.
Bei nanoCUL z.B. musst Du dagegen nach ggf. nötiger Anpassung compilieren. Dazu gibt's hier im Thread einige Hinweise.

Wenn Du der Hardware entsprechend geflashed hast, dann würde Log Info mit verbose 4 oder 5 helfen.

Gruß, Ansgar.

dog_martin

Danke für die Info!

Ja, es ist ein CUL V3.4 - ich habe den CUL mit der 1.66 aus fhem/FHEM/firmware erst einmal wieder funktionstüchtig bekommen...
Was da schief gelaufen ist kann ich im Moment nicht mehr sagen...

Der CUL wurde zwar erkannt, weigerte sich jedoch Befehle entgegen zu nehmen.
Ich werde es später nochmals testen und berichten.

dog_martin

Das Flashen der fertigen CUL_V3.hex läuft ohne Fehler durch.
Dann ersetzte ich lediglich die 00_CUL.pm in /opt/fhem/FHEM/.

Nach einem reboot kann der CUL nicht mehr initialisiert werden: Cannot init /dev/ttyACM0, ignoring it (CUL_0)

Das Ganze ist reversibel. Also kann's doch eigentlich kein Bedienerfehler sein!?

noansi

#208
Hallo Dog,

ZitatDann ersetzte ich lediglich die 00_CUL.pm in /opt/fhem/FHEM/.
und warum meinst Du, dass ich die anderen .pm Dateien mit ins zip gepackt habe?
DevIo.pm und 10_CUL_HM.pm müssen für Homematic auch minimal mit getauscht werden.

... danach zieh bitte mal CUL und steck ihn neu an. Vielleicht hilft noch ein Hard Reset des CUL.
Und setze bitte für CUL das attribut verbose auf 5 in der fhem.cfg -> Neustart und dann bitte nochmal das Log.

Auf einer Console bitte mal
lsusb
ausführen und schauen, ob da ein Atmel Corp. LUFA USB device auftaucht.
Möglicherweise hat Dein System CUL auf einen anderen Anschluss als /dev/ttyACM0 gemappt.
Dann mal einen System Neustart probieren.

EDIT: ein
dmesg
zeigt Dir auch auf welche Schnittstelle CUL gemappt wurde.

Gruß, Ansgar.

dog_martin

Hi Ansgar!
Zitat von: noansi am 03 September 2016, 15:50:18
DevIo.pm und 10_CUL_HM.pm müssen für Homematic auch minimal mit getauscht werden.
Ja, hatte ich natürlich auch mitgenommen...
Zitatdmesg
zeigt Dir auch auf welche Schnittstelle CUL gemappt wurde.
Die beiden USB Geräte (CUL und ZWDongle) habe doch tatsächlich nach Flashen Deiner Firmware die devs getauscht und nach Flashen der 1.66er wieder zurück!?
Deswegen funktionierte alles wieder mit der ursprünglichen FW...

Ich kann jetzt endlich ein wenig testen.
Mir ist aufgefallen, dass im Log jetzt jede Menge CUL_XmitDlyHM und CUL_ParseTsHM Meldungen auftauchen.
Kann ich das später auf ein sinnvolles Maß reduzieren (verbose ist 3).