Servus,
ich habe gerade meinen neuen CUL geflashed und in FHEM eingebunden mit
define CUL1 CUL /dev/ttyACM0 1234Im Log stand jetzt folgendes
Zitat2015.12.14 08:59:21 3: Opening CUL1 device /dev/ttyACM0
2015.12.14 08:59:21 3: CUL1 device opened
2015.12.14 08:59:21 3: CUL1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.12.14 08:59:21 2: Setting CUL fhtid from FFFF to 1234
2015.12.14 08:59:45 3: FHT Unknown device 070a, please define it
2015.12.14 08:59:45 2: autocreate: define FHT_070a FHT 070a
2015.12.14 08:59:45 2: autocreate: define FileLog_FHT_070a FileLog ./log/FHT_070a-%Y.log FHT_070a
2015.12.14 08:59:45 2: autocreate: define SVG_FHT_070a SVG FileLog_FHT_070a:fht:CURRENT
Wo kommt da jetzt das Gerät her ? Also das FHT 070a ?
Google kennt das gar nicht.
Was ich hier sonst noch in FHEM eingebunden habe und was funkt
- MAX Thermostate, Fensterkontakte, EcoTaster über MAXLAN
- HM USB mit Steckdose und Klingeltaster
- FritzDECT
der Rest ist "kabelgebunden"
Im Logfile zum FHT 070a steht
FHT_070a actuator: 100%davon tauchen immer 2 Einträge zur selben Zeit auf
Hat jemand ne Idee was das ist ?
FHT80b vom freundlichen Nachbar ?
neee war kein Schreibfehler, da steht 70a im Log
Zitatneee war kein Schreibfehler, da steht 70a im Log
:)
Wzut meint vermutlich FHT80b der Nachbar mit der ID 070a. Ich bin seiner Ansicht.
Zitatdavon tauchen immer 2 Einträge zur selben Zeit auf
Das sollte normalerweise nicht sein, es sei denn, man hat in FHEM mit "set CUL raw X.." experimentiert. Falls wir das debuggen sollten, dann bitte ein "attr global verbose 5" Mitschnitt mit gesetzten "attr global mseclog" hier anhaengen.
Zitates sei denn, man hat in FHEM mit "set CUL raw X.." experimentiert.
nicht das ich wüsste, ich weiß nicht mal was das ist ^^
2015.12.14 17:53:20.675 4: CUL_Parse: CUL1 T070A0026FF07 -70.5
2015.12.14 17:53:20.677 5: CUL1 dispatch 810c04xx0909a001070a000026ff
2015.12.14 17:53:20.678 4: FHT FHT_070a actuator: 100%
2015.12.14 17:53:20.679 5: Triggering FHT_070a (1 changes)
2015.12.14 17:53:20.680 5: Notify loop for FHT_070a actuator: 100%
2015.12.14 17:53:20.685 5: Notify from Device: FHT_070a recieved
2015.12.14 17:53:20.687 5: DbLog: logging of Device: FHT_070a , Type: FHT , Event: actuator: 100% , Reading: actuator , Value: 100 , Unit: %
2015.12.14 17:53:20.776 5: CUL/RAW: /T070A00A6FF08
2015.12.14 17:53:20.777 4: CUL_Parse: CUL1 T070A00A6FF08 -70
2015.12.14 17:53:20.778 5: CUL1 dispatch 810c04xx0909a001070a0000a6ff
2015.12.14 17:53:20.779 4: FHT FHT_070a actuator: 100%
2015.12.14 17:53:20.780 5: Triggering FHT_070a (1 changes)
2015.12.14 17:53:20.780 5: Notify loop for FHT_070a actuator: 100%
2015.12.14 17:53:20.786 5: Notify from Device: FHT_070a recieved
2015.12.14 17:53:20.788 5: DbLog: logging of Device: FHT_070a , Type: FHT , Event: actuator: 100% , Reading: actuator , Value: 100 , Unit: %
hoffe das reicht
Ueblicherweise versenden FHTs jeweils zwei gleiche Funktelegramme alle 2 Minuten, um die Ventile zu steuern. Dieses FHT versendet eins mit "Attribut" 26, und eins mit A6, deswegen werden sie nicht als doppelt im Firmware (culfw) ausgefiltert. Wenn ich mich recht erinnere, bedeutet 26 "neues Ventilwert" und A6 "Ventilwert hat sich nicht geaendert". Bisher habe ich nur 2 gleiche Nachrichten beobachtet. Was korrekt bzw. Fehler ist, kann ich nicht sagen, da ich die Protokolldokumentation nie gesehen habe.