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

[noansi]

Hallo Frank,

Code Auswählen Erweitern

#define VERSION_1               01
#define VERSION_2               66
#define VERSION                 "1.66"
ergibt Version 1.66 .

Gruß, Ansgar.

[noansi]

Hallo theophilou85,

Bis vor zwei Tagen hat sie noch richtig geschalten.

- Schaltet sie noch mit der zugehörigen Fernbedienung? Sprich, funktioniert die Lampe noch inklusive Leuchtmittel?
- Hast Du zu diesem Zeitpunkt was geändert? Z.B. ein FHEM Update gefahren? Oder den Empfang durch irgendwelche Umbauten in der Bude verschlechtert (Du sendest ja eh schwach)? CUL Position verändert usw.
- Hast Du mal die Sendefrequenz etwas variiert (Attribut  ITfrequency)? Temperaturveränderungen können dabei eventuell auch eine Rolle spielen.
- Hast Du mal geprüft, ob der Code, der gesendet wird (also das was mit verbose 5 im Log erscheint), auch richtig ist?

Code Auswählen Erweitern

sehr wohl aber alle anderen IT-Devices
Daher sehe ich auch erst mal keinen Grund für Dein Problem bei der Firmware. Gesendet wird es als Intertechno_V3.
Was AC im speziellen ggf. anders sendet weiß ich nicht, da müsstest Du mal Infos zu suchen.

Unterstützt deine Firmware eigentlich: TRX_LIGHT.pm?

leider nein.
Aber wenn eine der letzten 2 Fragen Dein Problem löst, dann würde das auch nicht helfen.

Gruß, Ansgar.

[theophilou85]

Hallo Ansgar

Erstmal danke für deine Zeit, "Theo" ist übrigens mehr als ausreichend.
Lampe funktioniert mit FB, CUL bewegte sich keinen Millimeter und ich dachte auch nichts geändert zu haben: "falsch": Ich hatte die fhem.save im Zuge des Löschens der Logs mitgelöscht.

Ich habe keine Ahnung ob das einen Sinn macht, aber ich kann es immer(!) rekonstruieren:
Aktuelle fhem.save -->Lampe schaltet nicht:

Code Auswählen Erweitern

2017.01.17 23:46:33 2: TSCUL_Parse: wz0_cul00 new condition Warning-HighLoad
2017.01.17 23:46:33 2: TSCUL_Parse: wz0_cul00 new condition ERROR-Overload
2017.01.17 23:46:38 2: wz0_cul00 IT_set: wz0_del00_sch00 off
2017.01.17 23:46:38 5: wz0_cul00 IT_set: Type=TSCUL Protocol=V3
2017.01.17 23:46:43 5: IT_Set: GetFn(raw): message = is00100000100001100110010110001000 Antwort =   raw => LOVF
2017.01.17 23:46:43 2: IT IODev device didn't answer is command correctly:   raw => LOVF
2017.01.17 23:46:44 3: wz0_cul00: Unknown code is00100000100001100110010110001000, help me!

fhem.save eines alten Backups (sonst alle Dateien gleich)

Code Auswählen Erweitern

2017.01.17 23:48:16 2: TSCUL_Parse: wz0_cul00 new condition Warning-HighLoad
2017.01.17 23:48:16 3: CUL_HM set wz0_inm00_Schalter1 statusRequest
2017.01.17 23:48:17 3: TSCUL_XmitDlyHM:  wz0_cul00  id:2FF75C dDly:14 toms:51
2017.01.17 23:48:17 3: TSCUL_XmitDlyHM:  wz0_cul00  id:2FF75C dDly:74 toms:50
2017.01.17 23:48:17 2: TSCUL_Parse: wz0_cul00 new condition ERROR-Overload
2017.01.17 23:48:23 2: wz0_cul00 IT_set: wz0_del00_sch00 off
2017.01.17 23:48:23 5: wz0_cul00 IT_set: Type=TSCUL Protocol=V3
2017.01.17 23:48:28 5: IT_Set: GetFn(raw): message = is00100000100001100110010110000000 Antwort =   raw => is00100000100001100110010110000000

Ergibt das Sinn?

[noansi]

Hallo Theo,

2017.01.17 23:46:33 2: TSCUL_Parse: wz0_cul00 new condition ERROR-Overload

Sendezeit Limit erreicht (1% Regel)

2017.01.17 23:46:43 5: IT_Set: GetFn(raw): message = is00100000100001100110010110001000 Antwort =   raw => LOVF

Sendezeit Limit erreicht (1% Regel)

Warten bis wieder genügend credits angesammelt sind (get credits bei CUL).

Ich hatte die fhem.save im Zuge des Löschens der Logs mitgelöscht.

ganz schlechte Idee, weil HM dann versucht alle Register von allen devices neu zu lesen.
autoreadreg readallmissing nutzen und HMInfo mit autosave.

Gruß, Ansgar.

[theophilou85]

Hi Ansgar

Gehe ich richtig in der Annahme dass du das attr autoUpdate für hm (define hm HMinfo) meinst? Ich frage lieber einmal mehr, bevor ich mir wieder etwas zerschieße

[Bastel-Frank]

Hallo Ansgar,

mit:

Code Auswählen Erweitern

#define VERSION_1               01
#define VERSION_2               66
#define VERSION                 "1.66"
ergibt Version 1.66 .

meldet mir das OTA-Tool leider dann, dass nur die Version 0.66 geflasht wurde. Kannst Du das bitte bei Dir kurz testen?

Viele Grüße
Frank

[Bastel-Frank]

... hmm, komisch. In den Internals wird die Version mit 1.66 angegeben. Das OTA-Tool meldet aber, dass nur Version 0.66 vorliegt 

[noansi]

Hallo Theo,

für HMInfo nutze ich folgende Definition:

Code Auswählen Erweitern

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 event-on-update-reading ERR_battery
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
sumERROR und sumStatus musst Du ggf. nach Deinen Wünschen anpassen. Siehe auch commandref und wiki etc.

Bei den einzelnen HM devices nutze ich in der Regel das:

Code Auswählen Erweitern

attr <devicename> autoReadReg 5_readMissing
um nur nicht bereits gelesene Register nochmal vom device zu holen, was die credits gerade beim Start von FHEM schont, da dadurch viel an die devices gesendet werden muss. Und fhem.save lösche ich nie (bewußt), eben auch, um die credits beim FHEM Start zu schonen. Für den Normalbetrieb habe ich bisher keine Einschränkungen wegen mangelnder credits bemerken können.

Und

Code Auswählen Erweitern

attr <devicename> expert 3_allReg+raw
um möglichst viel Registerwerte zu Gesicht zu bekommen.

Gruß, Ansgar.

[noansi]

Hallo Frank,

was spricht gegen einen Firmware Update Versuch aus FHEM herraus, wie ich es mal vorgeschlagen hatte, wozu Du aber nichts geschrieben hast?
Du mußt das device erst mal pairen und dann solltest Du den credits Stand checken und kannst einen Firmwareupdate mit dem device versuchen.

In den Internals wird die Version mit 1.66 angegeben.

Deswegen muss ich das auch nicht testen. 

Das OTA-Tool meldet aber, dass nur Version 0.66 vorliegt

Dann kommt das OTA-Tool wohl mit der VTS Versionskennung nicht klar.
Die ist einfach in fncollection.c von VTS in V zu ändern. Nur wird es dann völliger Murks, da ich das VTS gerade wegen eindeutiger Unterscheidung von TS Firmware gewählt habe.

Richtiger wäre, wenn der OTA-Tool Entwickler sich der Versionsproblematik mal annehmen würde. Der dann auch direkt einen check auf ausreichend credits einbauen sollte, sofern nicht schon geschehen. Und dann auch mit Timestamp Rückmeldungen klar kommen sollte, da ich die ohnehin künftig stets per default aktiv habe und auch die Abschaltung weglasse.

Du kannst natürlich auch einfach mal die Standard Firmware flashen, damit Dein Update mit dem OTA Tool fahren und dann wieder die TS Firmware flashen, um die Sache abzukürzen.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Ansgar,

vielen Dank für deine Hilfe und Geduld.

Ich möchte den Universalsensor (von Dirk hier aus dem Forum) updaten. Dieser unterstützt das normale fhem-fw-Update von der Komandozeile leider nicht. Daher kann man den von Dir vorgeschlagenen Standard-Weg nicht einschlagen.

Da es mit dem OTA-Tool wohl nicht gehen wird, kürzen wir die Sache dann tatsächlich ab und ich begebe mich ans Flashen ...

Viele Grüße
Frank

[theophilou85]

Hallo Ansgar

Danke für den Tipp, habe ich gleich umgesetzt. Wie steht es eigentlich um "autoReadReg" beim Actiondetector? Hast du den auch auf 5?

[noansi]

Hallo Theo,

Wie steht es eigentlich um "autoReadReg" beim Actiondetector? Hast du den auch auf 5?

Das Attribut macht da keinen Sinn, weil das kein Funk device ist, von dem Register zu lesen wären.

Gruß, Ansgar.

[noansi]

Hallo Frank,

Michael hat den Support für tsculfw jetzt in sein Firmware Update Tool 1.03 eingebaut.
Damit könntest Du einen neuen Versuch starten, ohne CUL umflashen zu müssen.

Gruß, Ansgar.

[theophilou85]

Hi Ansgar

Ich habe meine HMinfo und die autoreadreg der Hm-Devices jetzt so eingestellt wie du vorgeschlagen hast:

Code Auswählen Erweitern

define ActionDetector CUL_HM 000001
attr ActionDetector actCycle 600
attr ActionDetector actStatus
#attr ActionDetector autoReadReg 4_reqStatus
attr ActionDetector event-on-change-reading .*
attr ActionDetector expert 2_full
attr ActionDetector group FHEM
attr ActionDetector model ActionDetector

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 sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
attr hm_info sumStatus battery,sabotageError,powerError,motor
attr hm_info webCmd update:protoEvents short:rssi:peerXref:configCheck:models

attr wz0_the00 autoReadReg 5_readMissing
...
attr wz0_kon01 autoReadReg 5_readMissing
...


Bekomme aber selbst wenn keiner zu Hause ist und kein IT-Devices oder sonst irgendwas schalten muss, nach einigen Stunden folgende Fehlermeldung:

Code Auswählen Erweitern

2017.01.23 08:03:11 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9108.
2017.01.23 23:11:54 1: reload: Error:Modul 99_myUtils deactivated:

2017.01.23 23:11:54 1: starting in console mode

Komme ich dann nach Hause lassen sich die IT-Devices nicht mehr schalten.

Das einzige, dass mir bei der Sache auffällt ist: Ich habe kein /opt/fhem, da ich FHEM ja als Dienst unter Windows laufen lasse (nicht mehr lange). Oder hängt sich das FHEM wegen dem MyUtils auf? Darin habe ich aktuell aber nur den Addlog. Ich deaktiviere diesen einmal zum Test.

[noansi]

Hallo Theo,

Ich habe kein /opt/fhem

Dann must Du das wohl beim attribut configDir anpassen. Wenn Du es gant weg läßt, dann wird als default ein . genommen, laut code.

Unter Linux auf dem RasPi ist /opt/fhem das default Installationsverzeichnis.  Wo es unter Windows ist, kann ich nicht sagen. Stell die Frage bitte nochmal im Homatic Forum.

Gruß, Ansgar.