Hallo,
nach heutigen update funktioniert meine gesamte Homematic konfiguration nicht mehr.
Alle 'channels' aller Devices, ausser 'channel_01' sind verschwunden.
Ausserdem bekomme ich folgende Fehlermeldung für alle Homematic devices:
unknown attribute .mId
Das dürfte das gleiche Problem wie beim Vorredner sein. https://forum.fhem.de/index.php/topic,95405.0.html
Wenn man das alte CUL_HM wieder zurückspielt, und ein get config macht, bekommt mann immer ein "RESPONSE TIMEOUT:RegisterRead".
Super. Jetzt hab ich dummerweise gerade vor 30 Minuten ein Update gemacht. Alle CUL_HM wie von Dir beschrieben. *GRRR*
wer heute ein update gemacht hat,
sollte da /opt/fhem/restoreDir/update/2019-01-06
auch die "alte" vor update" fhem.cfg liegen haben ;)
Update:
Es ist wohl so, das man nach dem Update von heute morgen alle Geräte komplett neu anlernen muss. Das update an sich ist in Ordnung.
Weil ich jetzt sowieso alles neu anlernen musste, habe ich probehalber die neuen 00_HMLAN.pm und 10_CUL_HM.pm (also das update von heute morgen) doch nochmal eingespielt,
und nach dem neu anlernen sind alle Channels wieder da. Aber alle user attribute der Channels sind natürlich weg, etc.
backup einspielen und fertig
Das ist natürlich quatsch. Bitte darüber informieren, was Anlernen (pairen) bedeutet. Und ein restore sollte gehen. Backup einspielen auch.
Korrekt, Backup einspielen hat geholfen.
Ich kann mich kaum beklagen. FHEM war zwar nach dem Update (und shutdown restart) tot (fhem start scheiterte wegen fehlender zugriffsberechtigungen auf das aktuelle log file); manuelles Neustarten via Console hilf auch nicht. Fix Raspi neu gestartet und dann brauchte FHEM etwas zum Starten aber dann ging es. Und nun läuft es.
Probleme mit den HM Devices kann ich nicht bestätigen. Pairing blieb bestehen, via VCCU konnte auch HM Devices schalten, auslesen (getconfig) etc.; Kanäle sind auch vorhanden. Also bis auf das verschlucken beim Neustart läufts.
Ich hab nur einige Warnings im Log:
Zitat
2019.01.06 16:16:30 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 8539.
2019.01.06 16:16:30 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 6591.
2019.01.06 16:16:30 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 6595.
2019.01.06 16:16:32 1: PERL WARNING: Use of uninitialized value $cmdS in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4118.
Hallo,
Bei mir tritt besagtes Verhalten auch auf.
Alternativ zum Backup hat bei mir funktioniert bei allen Geräten mit
attr HM_Name modelForce GeräteBezeichnung
die Gerätebezeichnung neu zu setzen. Dadurch wird automatisch auch das Attribut "model" gesetzt. Ist natürlich Aufwand...
Das Attribut modelForce kann danach wieder gelöscht werden.
Gruß,
Jürgen.
Ich frage einfach mal blöd nach dem aktuellen Stand, bevor noch mehr User Probleme haben und es dann wieder zig neue Threads gibt...
- Was ist die Ursache? (nur die Cul_HM?)
- Wird das fehlerhafte Modul weiterhin per Update verteilt?
- Was muss nach einem Restart gemacht werden?
- Was kann vor einem Restart gemacht werden?
Derzeitiger Kenntnisstand (bitte korrigieren):
- einfachster Weg ist das Einspielen der 10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg aus dem Restore-Ordner
Tja, mich hat's auch erwischt... "RESPONSE TIMEOUT:RegisterRead" überall... mir ist auch noch nicht ganz klar, was zu tun ist...
Hat mal einer den Maintainer angeschrieben?
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: breti am 06 Januar 2019, 20:59:25
Tja, mich hat's auch erwischt... "RESPONSE TIMEOUT:RegisterRead" überall... mir ist auch noch nicht ganz klar, was zu tun ist...
Restore oder Backup einspielen. Grundlagen, mit denen man sich vor dem Produktiveinsatz einer solchen Software beschäftigen MUSS.
Zitat von: Frank_Huber am 06 Januar 2019, 21:01:04
Hat mal einer den Maintainer angeschrieben?
Hab ihn per "Moderator informieren" auf diesen Thread hingewiesen, da der Moderator zufällig auch Maintainer der besagten Module ist. :)
Zitat von: sensorle am 06 Januar 2019, 18:01:56
Alternativ zum Backup hat bei mir funktioniert bei allen Geräten mit
attr HM_Name modelForce GeräteBezeichnung
die Gerätebezeichnung neu zu setzen. Dadurch wird automatisch auch das Attribut "model" gesetzt. Ist natürlich Aufwand...
Mich hat es auch erwischt. Der Subtype bei den Devices wird gelöscht. Mit Modelforce wird es wieder gesetzt.
Muss man Modelforce löschen oder kann es auch als Attribut gesetzt bleiben?
Gruß Udo
irgendwie wird die Liste unter allr global exclude_from_update immer länger... Dabei findet jeder Entwickler mit Sicherheit 3-4 User mit unterschiedlichen Settings, welche gern bereit sind, die Module vor der Veröffentlichung auf Nebenwirkugen zu testen. Gibt es hier inzwischen Neuigkeiten, die ich überlesen habe?
attr HM_Name modelForce GeräteBezeichnung half leider bei meinem virtuellen doorcontakt nicht weiter
Zitat von: det. am 07 Januar 2019, 11:14:55
irgendwie wird die Liste unter allr global exclude_from_update immer länger... Dabei findet jeder Entwickler mit Sicherheit 3-4 User mit unterschiedlichen Settings, welche gern bereit sind, die Module vor der Veröffentlichung auf Nebenwirkugen zu testen. Gibt es hier inzwischen Neuigkeiten, die ich überlesen habe?
attr HM_Name modelForce GeräteBezeichnung half leider bei meinem virtuellen doorcontakt nicht weiter
Und du glaubst, bei 3-4 Usern wird tatsächlich jedes Problem gefunden? Du bist auf dem Holzweg. Man muss wissen, auf was man sich einlässt, wenn man eine Software, wie FHEM einsetzt. Wenn man sich dementsprechend verhält, ist die Wahrscheinlichkeit, dass man in solche Fallen tappt sehr gering.
Natürlich kann man vom Entwickler Sorgfalt erwarten, aber nichts unmenschliches. Als User hingegen hat man alle Möglichkeiten, solche Probleme zu vermeiden. Das geht zwar nicht immer, dafür aber sehr einfach.
warum macht ihr überhaupt ein update, wenn es scheinbar so schlimm ist. ohne update braucht es auch kein exclude_from_update.
und wenn man nur einen bestimmten fix benötigt, kann man auch ein modul exclusiv updaten, ohne den rest zu gefährden.
ein update in fhem ist zwar kostenlos, aber nicht umsonst. ;)
Zitat von: marvin78 am 07 Januar 2019, 11:29:18
Wenn man sich dementsprechend verhält, ist die Wahrscheinlichkeit, dass man in solche Fallen tappt sehr gering.
Als neuer in diesem Forum möchte ich gerne Fragen, was das genau meint?
Ich bin z.B. in das Problem gelaufen, weil ich etwas neues in FHEM installiert habe. In jedem Wiki Artikel steht man soll vorher ein Update von FHEM durchführen, um auch immer aktuell zu sein. Gesagt, getan...
So schnell war dann auch das Problem da.
Meine Frage ist nicht kritisch gemeint sondern durchaus mit dem Versuch einen guten Prozess zu finden FHEM und all seine Module lauffähig aber doch aktuell zu halten.
Vielen Dank im Voraus.
Zitat von: Hollo am 06 Januar 2019, 20:26:08
Ich frage einfach mal blöd nach dem aktuellen Stand, bevor noch mehr User Probleme haben und es dann wieder zig neue Threads gibt...
- Was ist die Ursache? (nur die Cul_HM?)
- Wird das fehlerhafte Modul weiterhin per Update verteilt?
- Was muss nach einem Restart gemacht werden?
- Was kann vor einem Restart gemacht werden?
Derzeitiger Kenntnisstand (bitte korrigieren):
- einfachster Weg ist das Einspielen der 10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg aus dem Restore-Ordner
Habe die 10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg wieder eingespielt, dann einen shutdown restart durchgeführt.
Scheint wieder alles zu funktionieren.
Tut mir jetzt ja ein bisschen leid für Euch alle, denn die Vorversion hatte ich im Test, leider ist das Verhalten bei mir auch erst heute morgen nach einem weiteren Neustart (Speicherkarte gewechselt) aufgetreten, den vorigen Neustart hatte meine Konfig noch recht unbeschadet überlebt, da hatte es nur einen Aktor "zerlegt". Ich hatte aber nicht damit gerechnet, dass das jetzt ins SVN geht...
@Martin: Die Rekonstruktion der models aus dem .mId scheint fehlerhaft. Entgegen Deinen Ausführungen zu modelForce setzen und löschen hatte es dieses Attribut dann heute doch in alle meine HM-Geräte geschafft (nicht nur die bei denen modelForce gesetzt wurde). Und dann schlug die Rekonstruktion fehl, Beispiel:
define HM_266A77 CUL_HM 266A7
attr HM_266A77 .devInfo 110100
attr HM_266A77 .mId 0068
attr HM_266A77 .stc 20
...
attr HM_266A77 model HASH(0x57aa460)
...
attr HM_266A77 subType
Danach gingen so ziemlich alle Geräte auf "virtual" und alle Kanäle der Geräte wurden gelöscht.
Ich habe mir inzwischen angewöhnt, vor einem Update hier ins Unterforum zu schauen, ob es gerade ein mglw. problematisches Update gab. Irgendeine arme Sau ist dann leider immer das Versuchskaninchen...
Nachtrag: modelForce ist eine neue Funktion. Ich würde bis zur endgültigen Klärung diese Funktion nicht verwenden.
Zitat von: Udomatic am 07 Januar 2019, 12:17:46
Als neuer in diesem Forum möchte ich gerne Fragen, was das genau meint?
Testsystem, vor dem Update ins Forum schauen, nur das updaten, was man benötigt.
Es handelt sich hier nicht um ein Consumerprodukt. Ich sage es immer wieder gerne: FHEM ist nichts für Leute, die sich nicht voll darauf einlassen. Das heißt für mich auch, dass man immer und überall weiß, was man tut. Und das geht nun einmal darüber hinaus, nur Anleitungen zu lesen. Man muss das Vorgehen verstehen und dann weiß man auch, was man zu tun hat, um ähnliche Dinge zu vermeiden. Zur Not weiß man eben, wie ein restore funktioniert und man ist sicher. Wer das nicht kann, lasse bitte die Finger von FHEM oder lebe damit, dass man was nicht so einfach ist. Auf den Entwickler einhauen, ist immer falsch.
Mich hatte es leider auch erwischt, noch bevor ich diesen Beitrag hier gefunden habe.
10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg eingespielt + shutdown restart und alles läuft erstmal wieder.
Zitat von: det. am 07 Januar 2019, 11:14:55
irgendwie wird die Liste unter allr global exclude_from_update immer länger...
Gibt es noch mehr solche Pannen in FHEM? :-\
10_CUL_HM.pm kommt jetzt erst mal sicherheitshalber auf die Liste. Ist zwar unschön, aber wie schon treffend gesagt: Vorwürfe sind unangebracht.
Zitat von: Pfriemler am 07 Januar 2019, 16:50:27
Gibt es noch mehr solche Pannen in FHEM? :-\
10_CUL_HM.pm kommt jetzt erst mal sicherheitshalber auf die Liste. Ist zwar unschön, aber wie schon treffend gesagt: Vorwürfe sind unangebracht.
Zur Frage, ja Pannen würde ich das nicht unbedingt nennen, sind zum Teil auch Module mit selbst gefixten Sachen, die sonst beim nächsten Update wieder weg sind und ne Liste kann ich Dir höchstens per pm zukommen lassen wegen:
angeblicher Vorwürfe - ich hatte das als gutgemeinten Hinweis gedacht, aber von Hero Member mit 3jahre späterem Fhem Einstieg, aber 5-7 mal mehr Postings in der kürzeren Zeit muss ich mich nicht schulmeistern lassen.
Zitat von: Pfriemler am 07 Januar 2019, 16:50:27
Gibt es noch mehr solche Pannen in FHEM? :-\
10_CUL_HM.pm kommt jetzt erst mal sicherheitshalber auf die Liste. Ist zwar unschön, aber wie schon treffend gesagt: Vorwürfe sind unangebracht.
Naja das ist immer so, wenn man Software aktualisiert (und das soll keine Entschuldigung sein). Selbst Microsoft muss Updates gelegentlich (und in letzter Zeit häufiger) zurückziehen, weil etwas nicht funktioniert hat (und die Dinge bei Leuten gelöscht wurden etc.). War ja auch nicht das erste mal bei CUL_HM - aber ich benutze hier geschenkte Software und habe halt keinen Anspruch darauf, dass sie absolut fehlerfrei ist.
Deswegen: Testsystem und dann halt individuell testen / eine eigene QA dahinter bauen. Ich gucke mir z.B. die Commits für die Module, die ich benutze, in Normalfall mal vorher an bevor ich das System aktualisiere, auch weil ich ein paar Patches habe, die ich nach einem Update einspiele.
Zitat von: det. am 07 Januar 2019, 19:25:12
Zur Frage, ja Pannen würde ich das nicht unbedingt nennen, sind zum Teil auch Module mit selbst gefixten Sachen, die sonst beim nächsten Update wieder weg sind und ne Liste kann ich Dir höchstens per pm zukommen lassen wegen:
angeblicher Vorwürfe - ich hatte das als gutgemeinten Hinweis gedacht, aber von Hero Member mit 3jahre späterem Fhem Einstieg, aber 5-7 mal mehr Postings in der kürzeren Zeit muss ich mich nicht schulmeistern lassen.
::) denk einfach nochmal nach. Bin raus.
Kann mir mal bitte jemand sagen welche Version das genau betrifft? Ich hatte gestern ein Update gemacht aber noch sieht alles gut aus. Ich habe nur Probleme mit einem virtual_1 device wo ich die Temp nicht mehr setzen kann, warum auch immer. Kann aber auch ein anderes Problem sein.
Ich habe derzeit:
# $Id: 10_CUL_HM.pm 18153 2019-01-05 23:21:58Z martinp876 $
# $Id: 00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876 $
/Daniel
https://forum.fhem.de/index.php/topic,93930.msg883035/topicseen.html#new (https://forum.fhem.de/index.php/topic,93930.msg883035/topicseen.html#new)
lesen bildet
wer traut sich zu testen , laden aus dem SVN?
Zitat von: ext23 am 07 Januar 2019, 20:20:23
Kann mir mal bitte jemand sagen welche Version das genau betrifft? Ich hatte gestern ein Update gemacht aber noch sieht alles gut aus. Ich habe nur Probleme mit einem virtual_1 device wo ich die Temp nicht mehr setzen kann, warum auch immer. Kann aber auch ein anderes Problem sein.
Ich habe derzeit:
# $Id: 10_CUL_HM.pm 18153 2019-01-05 23:21:58Z martinp876 $
# $Id: 00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876 $
/Daniel
Die hier müssten die letzten funktionierenden davor gewesen sein:
00_HMLAN.pm (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_HMLAN.pm?rev=18041) Rev. 18041
10_CUL_HM.pm (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_CUL_HM.pm?rev=18113) Rev. 18113
Ahh misst ok dann spiele ich auch mal lieber die alten wieder ein, dann habe ich auch schon das faule Ei erwischt, egal.
Danke.
UPDATE: OK alten Module und die 20 config files mit einem compare tool manuell angepasst, das waren zum großen Teil diese ganzen mID Einträge in den ATTRs die ich entfernt habe. Ich hatte dummerweise gestern seit 3 Wochen mal wieder ein Update gemacht und ausgerechnet an dem Tag auch noch etliche Sachen geändert. Gut selber Schuld, passiert.
Läuft wieder.
/Daniel
Hallo zusammen,
mich hat es auch voll erwischt. Update gestern (weil ich MQTT2Server nutzen will), letztes Update bestimmt halbes Jahr her (never change a running system).
Voll eingeschlagen hat es erst heute nach dem nächtlichen Reboot - warum weiß ich nicht, weil ich ja den System-Updates gestern schon mehrere Reboots durchgeführt hatte.
Neu anlernen bei 60+ Homematic-Devices keine Option! Erschwerend kam hinzu, dass bei mir manche Kanäle noch das alte Namensschema haben (_Clim_tr bei Heizkörperthermostaten) und da unzählige notifies, DOIFs etc. drauf zugreifen.
Zum Glück vorher auch ein Full Image-Backup mit raspibackup.sh gezogen, deshalb hielt sich mein Puls-Anstieg in Grenzen, wobei ich tatsächlich kurz dachte, das Pairing sei verloren gegangen (was ja nicht sein kann).
Zitat von: webdandy am 07 Januar 2019, 16:33:51
Mich hatte es leider auch erwischt, noch bevor ich diesen Beitrag hier gefunden habe.
10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg eingespielt + shutdown restart und alles läuft erstmal wieder.
Das hat geholfen. Rest vom Update habe ich auf Stand 06.01.2019 gelassen.
Viele Grüße,
Heiko
Leider hat es mich auch erwischt... :-\
Habe dann glücklicherweise ein Backup gehabt und daraus das /opt/fhem/FHEM Verzeichnis wiederhergestellt. Nach Reboot scheint alles OK zu sein. Mal abwarten.
Wie kann ich die betroffenen Module vom Update ausschließen?
Hat jemand eine Idee?
Liebe Grüße
Jörg
Hey Jörg,
mit
attr global exclude_from_update ...
kannst du einzelne Module vom allgemeinen Update ausschließen, und dann manuell einzeln updaten.
martins änderungen von gestern zeigen wirkung.
ich habe gerade ein fhem update gemacht und habe noch keine probleme bemerkt.
edit:
leider doch noch probleme: mindestens beim teamlead device fehlt jetzt das attr subType.
Ich warte mal lieber trotzdem noch bis morgen.
Schade aber, dass er nicht mal kurz was hier in den Thread geschrieben hat.
Zitat von: Loki am 08 Januar 2019, 11:14:46
Ich warte mal lieber trotzdem noch bis morgen.
Schade aber, dass er nicht mal kurz was hier in den Thread geschrieben hat.
vielleicht wollte er dem shitstorm aus dem wege gehen? ;)
ich habe gerade noch 2 "schönheitsfehler" bemerkt, die ich ihm hier beschrieben habe:
https://forum.fhem.de/index.php/topic,93930.msg883725.html#msg883725 (https://forum.fhem.de/index.php/topic,93930.msg883725.html#msg883725)
Zitat von: Loki am 08 Januar 2019, 11:14:46
Ich warte mal lieber trotzdem noch bis morgen.
Schade aber, dass er nicht mal kurz was hier in den Thread geschrieben hat.
Es gibt auch Leute die arbeiten gehen und Familie haben.
Ihr dürft nicht vergessen dass alle Programmiere hier das in Ihrer Freizeit machen!
Ich denke er wird sich hier schon noch zu Wort melden.
Zitat von: Frank_Huber am 08 Januar 2019, 11:42:55
Es gibt auch Leute die arbeiten gehen und Familie haben.
Ihr dürft nicht vergessen dass alle Programmiere hier das in Ihrer Freizeit machen!
Ich denke er wird sich hier schon noch zu Wort melden.
Ich denke das ist hier mitlerweile jedem bewußt!Niemand braucht dann diese ständigen Moralpredigten.
Er hat sich außerdem in dem anderen Thread dazu geäußert.
ALLES OK!!!
Just my 2 Cent.
Leute, was ihr für Moralpredigt haltet, ist lediglich eine Information an Leute, denen die Vorstellungskraft fehlt, was andere Leute so mit ihrem Leben machen. Und ja, das muss offenbar immer wieder erwähnt werden. Man schaue nur in diesem Thread. Und es gibt deutlich schlimmere. Wer sich angesprochen fühlt, kann das ja auch gerne für sich behalten...
leider doch noch probleme:
mindestens beim teamlead device fehlt mir jetzt das attr subType, wodurch scheinbar wichtige events ausbleiben.
besser doch noch mit dem update warten, oder attribute fixen.
Zitat von: frank am 08 Januar 2019, 12:16:44
leider doch noch probleme:
mindestens beim teamlead device fehlt mir jetzt das attr subType, wodurch scheinbar wichtige events ausbleiben.
besser doch noch mit dem update warten, oder attribute fixen.
Irgendwelches Gemecker hilft keinem, Fehler ist passiert, schade, beim nächsten mal vermeiden und Ende.....und wir haben alle was gelernt. Das ist doch auch was.
Was meinst Du mit "attribute fixen". Was habe ich da zu tun? kannst Du mir einen Tipp geben?
Inzwischen reicht auch ein UPDATE + RESTART um das Problem zu beheben.
Danke für den Fix!
Wer nicht fixen will kann als letze lauffähige Version der 10_CUL_HM.pm ohne ModelForce die Revision @18133 vom 1.1.2019 aus dem SVN holen.
oder die allerletzen Fixes / Updates (rev.@18171) testen :D
Phantom
Hallo in die erregte Runde,
ich nutze das FHEM System jetzt seit über 4 Jahren als Umbrella für all meine Systeme (Homematic, Fritz Dect, Siemens Logo ..).
Es macht immer wieder Spaß und Freude, wie viele neuen Ideen ich damit umsetzen kann.
Die Tatsache, das aber Änderungen durchgeführt werden, ohne einen kleinen Kommentar im Change Log, hat schon zu der ein oder anderen Pulsspitze bei mir geführt.
Ich würde mir hier einfach in den Change Logs mehr Infos wünschen. Gerade was die Major Implementationen, wie Homemantic betrifft.
Meine Attribute zum "subtype", sind bei allen Devices gesetzt und wenn ich das Update lade, kann ich keines der Aktoren mehr schalten.
Alles kein Drama, da Fhem und ich immer ein Backup haben. Frei nach dem Moto, "Kann die Frau alles bedienen, freut sich der Herr des Hauses".
Gruß Andreas
Die Änderungen in der CUL_HM waren eigentlich "hinter den Kulissen". Die vorletzte Änderung, das Einpflegen von "readingsOnDead" als Datenbehandlungsmethode für ausgefallene Geräte, ging wie viele andere reibungslos über die Bühne. Auch hier sollte "modelForce" eigentlich gar nicht in den vorhandenen Datenbestand eingreifen.
Durch anfängliche Denkfehler tat es das dann doch, und zwar mit gravierenden Folgen. Ich kenne das aus eigener Erfahrung: Eigentlich ändert man nur eine Winzigkeit am Code, und schon funktioniert vieles nicht mehr, weil man eine Abhängigkeit übersehen hat.
Ich würde daraus folgende Lehren ziehen (aber ich bin kein Modulautor und überlasse die (Nicht-)Befolgung folglich denen die es wissen müssen, ohne deswegen sauer zu sein):
- Fehlerkorrekturen gehen immer und sollten so umgehend wie möglich umgesetzt werden.
- Möglicherweise (!) tiefergehende Änderungen und neue Funktionen sollten selbst und von einer Schar Mutiger getestet werden, alle Rückmeldungen ernstgenommen und genügend "läuft ok" gesammelt sein, bevor man dann eine Änderung annociert und dann mit Ankündigung umsetzt. Es ist ein Unterschied, ob man eine Änderung schnell fertig bekommen möchte und dann die Schar Tester im Stundentakt mit Korrekturen versorgt, oder ob man die Schar der Nutzer unvorbereitet in den Regen stellt.
- Geht dann doch mal was schief, muss keiner sauer sein, weil er ja ein Backup hat und es mit ein paar Handgriffen einstellen kann.
Und last but not least: Wir würden hier alle erst mal im Regen stehen, wenn der Modulautor kurzfristig ausfällt. Ich gucke da rein wie ein Schwein ins Uhrwerk. Aus Dankbarkeit nehme ich auch die eine oder andere ungeplante Wartungsarbeit dafür in Kauf.
Das Jahr 2018 hat etliche Fortschritte in HM gebracht, finde ich.
Sorry, für die misslungene Änderung. Ich hatte etliche updated reboots und restarts erfolgreiche getest.
Sorry, dass ich erst jetzt antworte : tagsüber muss ich Bröttchen verdienen.
Die alten Versionen sind wieder eingecheckt. Ein weiteres Update sollte funktionieren.
Betroffen sind 10_CUL_HM.pm und HMConfig.pm
Zu den Devices: Man muss nichts neu Pairen, peeren, oder Register setzen. FHEM /CUL_HM setzt ohne User Kommando NIE diese Einstellungen.
Zu den Configs: Wenn man ein Save macht bleiben alle Einstellungen erhalten. Readings konnten sich verändern.
Es würde also reichen, 10_CUL_HM.pm und HMConfig.pm wieder einzuspielen.
Nun würde mich noch interessieren, wer sinnvoll beschreiben kann, was bei ihm passiert ist. Ich habe auch Rachmelder und Teamleads - die sind sauber upgedated worden mit der neuen SW.
Die Änderungen werden kommen - und wenn ich die Probleme kenne, kann ich diese korrigieren und testen.
bspw: Das Attribut ".mId" ist in der neuen Version gültig, neu und ganz normal eingeführt. Es kann nicht zu Fehlermeldungen führen. Ist das der Fall brauche ich Details.
Hallo martin876,
Hier mal dazu 2 Bilder (sorry auf dem iPad geht es so am einfachsten) vom virtuellen Türkontakt. Bei der neusten Version im 2. Bild fehlt postEvent ... und damit die Möglichkeit dem virtuellen Kontakt einen Wert zuzuweisen. Vorher ging das wie im Wiki beschrieben.
Trotzdem großartige Leistung, HM ist ein zentrales und sehr weites Feld bei FHEM!
Hallo Martin
Ich habe bei jeden meiner HM Geräte folgende Fehlermeldung erhalten. (Türkontakte, Rolloschalter, Lichtschalter, Feuermelder)
Unknown argument on, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet templateDel tplSet_self01:DimOff_long,DimOff_short,DimOn_long,DimOn_short,SwCondAbove_long,SwCondAbove_short,SwCondBelow_long,SwCondBelow_short,SwOnCond_long,SwOnCond_short,motionOnDim_long,motionOnDim_short tplSet_self02:DimOff_long,DimOff_short,DimOn_long,DimOn_short,SwCondAbove_long,SwCondAbove_short,SwCondBelow_long,SwCondBelow_short,SwOnCond_long,SwOnCond_short,motionOnDim_long,motionOnDim_short
Zusätzlich war das attr subType virtual in der VCCU nicht mehr zulässig.
Mir blieb nur auf die alte Modulversion zurück zu gehen und sowohl model als auch subType neu zu setzen.
Bei model war auf einmal "HASH(0x5785710)" statt "HM-LC-Sw2PBU-FM"
und der subTyp war leer statt " switch"
Ich hoffe ich konnte weiter helfen. Sollten noch Fragen sein, oder ich etwas testen soll. Jederzeit gerne
Gruß
Daniel
00_HMLAN.pm 18152 2019-01-05
10_CUL_HM.pm 18184 2019-01-08
Mit diesen Dateien fhelt das Attributt virtTemp um die Funktion der virtuellen Temperatursensoren zu realisieren.
set OG1_STH_HZG_TC_Weather_vT_S virtTemp $temp
Update grade eben, nach shutdown restart:
2019.01.09 14:44:34 1: configfile: licht_buero: unknown attribute .mId. Type 'attr licht_buero ?' for a detailed list.
Selbe Meldung für alle meine HM Devices.
Nach dem Update vom 8.1. von HMConfig.pm kam bei mir zunächst nur folgende Fehlermeldung, mit der aber alles noch funktionierte:
PERL WARNING: Useless use of a variable in void context at FHEM/HMConfig.pm line 337, <$fh> line 304.
Nach dem heutigen Update kam dann für jedes Device eine Fehlermeldung wie folgt:
2019.01.09 08:48:21 3: Temp.Feuchte.Norden: unknown attribute .mId. Type 'attr Temp.Feuchte.Norden ?' for a detailed list.
2019.01.09 08:48:21 3: Temp.Dach: unknown attribute .mId. Type 'attr Temp.Dach ?' for a detailed list.
2019.01.09 08:48:21 3: CUL_HMLAN: unknown attribute .mId. Type 'attr CUL_HMLAN ?' for a detailed list.
2019.01.09 08:48:21 3: Licht.Eingang: unknown attribute .mId. Type 'attr Licht.Eingang ?' for a detailed list.
2019.01.09 08:48:21 3: Licht.Garten: unknown attribute .mId. Type 'attr Licht.Garten ?' for a detailed list.
2019.01.09 08:48:21 3: Thermostat.WZ.allg: unknown attribute .mId. Type 'attr Thermostat.WZ.allg ?' for a detailed list.
.....
Ich hoffe es hilft.
Danke vorab! Achim
Ich habe bei allen HM Geräten unbekannte Attribute. Fenstersensoren, Rauchmelder, Thermostate und Regler, Feuchtesensor usw.
configfile: VCCU: unknown attribute .mId. Type 'attr VCCU ?' for a detailed list.\
UEST1_AB_GAO: unknown attribute .mId. Type 'attr UEST1_AB_GAO ?' for a detailed list.\
UEST2_AB_GAO: unknown attribute .mId. Type 'attr UEST2_AB_GAO ?' for a detailed list.\
UESF1_AB_FR: unknown attribute .mId. Type 'attr UESF1_AB_FR ?' for a detailed list.\
UEST1_AB_FR: unknown attribute .mId. Type 'attr UEST1_AB_FR ?' for a detailed list.\
UEST1_AB_SA: unknown attribute .mId. Type 'attr UEST1_AB_SA ?' for a detailed list.\
UEST1_AB_GTW: unknown attribute .mId. Type 'attr UEST1_AB_GTW ?' for a detailed list.\
UESF1_AB_GAO: unknown attribute .mId. Type 'attr UESF1_AB_GAO ?' for a detailed list.\
UESF2_AB_GAO: unknown attribute .mId. Type 'attr UESF2_AB_GAO ?' for a detailed list.\
UESF1_EG_SL: unknown attribute .mId. Type 'attr UESF1_EG_SL ?' for a detailed list.\
UESF2_EG_SL: unknown attribute .mId. Type 'attr UESF2_EG_SL ?' for a detailed list.\
UESF1_EG_BA: unknown attribute .mId. Type 'attr UESF1_EG_BA ?' for a detailed list.\
UESF1_EG_WZ: unknown attribute .mId. Type 'attr UESF1_EG_WZ ?' for a detailed list.\
UESF2_EG_WZ: unknown attribute .mId. Type 'attr UESF2_EG_WZ ?' for a detailed list.\
UESF1_EG_KUE: unknown attribute .mId. Type 'attr UESF1_EG_KUE ?' for a detailed list.\
UEST1_EG_KUE: unknown attribute .mId. Type 'attr UEST1_EG_KUE ?' for a detailed list.\
UESF1_EG_WC: unknown attribute .mId. Type 'attr UESF1_EG_WC ?' for a detailed list.\
UESF1_EG_WI: unknown attribute .mId. Type 'attr UESF1_EG_WI ?' for a detailed list.\
UEST1_EG_STH: unknown attribute .mId. Type 'attr UEST1_EG_STH ?' for a detailed list.\
UESF1_EG_STH: unknown attribute .mId. Type 'attr UESF1_EG_STH ?' for a detailed list.\
UESF2_EG_STH: unknown attribute .mId. Type 'attr UESF2_EG_STH ?' for a detailed list.\
UESF3_OG1_STH: unknown attribute .mId. Type 'attr UESF3_OG1_STH ?' for a detailed list.\
UESF4_OG1_STH: unknown attribute .mId. Type 'attr UESF4_OG1_STH ?' for a detailed list.\
UESF5_OG2_STH: unknown attribute .mId. Type 'attr UESF5_OG2_STH ?' for a detailed list.\
UESF1_OG1_SL: unknown attribute .mId. Type 'attr UESF1_OG1_SL ?' for a detailed list.\
UESF2_OG1_SL: unknown attribute .mId. Type 'attr UESF2_OG1_SL ?' for a detailed list.\
UESF1_OG1_BA: unknown attribute .mId. Type 'attr UESF1_OG1_BA ?' for a detailed list.\
UESF1_OG1_WZ: unknown attribute .mId. Type 'attr UESF1_OG1_WZ ?' for a detailed list.\
UESF2_OG1_WZ: unknown attribute .mId. Type 'attr UESF2_OG1_WZ ?' for a detailed list.\
UESF1_OG1_KUE: unknown attribute .mId. Type 'attr UESF1_OG1_KUE ?' for a detailed list.\
UEST1_OG1_KUE: unknown attribute .mId. Type 'attr UEST1_OG1_KUE ?' for a detailed list.\
UESF1_OG1_WC: unknown attribute .mId. Type 'attr UESF1_OG1_WC ?' for a detailed list.\
UESF1_OG1_KI: unknown attribute .mId. Type 'attr UESF1_OG1_KI ?' for a detailed list.\
UESF1_OG2_BUE1_N: unknown attribute .mId. Type 'attr UESF1_OG2_BUE1_N ?' for a detailed list.\
UESF2_OG2_BUE1_N: unknown attribute .mId. Type 'attr UESF2_OG2_BUE1_N ?' for a detailed list.\
UESF3_OG2_BUE1_N: unknown attribute .mId. Type 'attr UESF3_OG2_BUE1_N ?' for a detailed list.\
UESF1_OG2_BUE2_N: unknown attribute .mId. Type 'attr UESF1_OG2_BUE2_N ?' for a detailed list.\
UESF2_OG2_BUE2_N: unknown attribute .mId. Type 'attr UESF2_OG2_BUE2_N ?' for a detailed list.\
UESF1_OG2_BUE2_W: unknown attribute .mId. Type 'attr UESF1_OG2_BUE2_W ?' for a detailed list.\
UESF2_OG2_BUE2_W: unknown attribute .mId. Type 'attr UESF2_OG2_BUE2_W ?' for a detailed list.\
UESF3_OG2_BUE2_W: unknown attribute .mId. Type 'attr UESF3_OG2_BUE2_W ?' for a detailed list.\
UESF1_OG2_DB: unknown attribute .mId. Type 'attr UESF1_OG2_DB ?' for a detailed list.\
UESF1_OG2_DBN: unknown attribute .mId. Type 'attr UESF1_OG2_DBN ?' for a detailed list.\
UESF2_OG2_DBN: unknown attribute .mId. Type 'attr UESF2_OG2_DBN ?' for a detailed list.\
UESF3_OG2_DBN: unknown attribute .mId. Type 'attr UESF3_OG2_DBN ?' for a detailed list.\
UEST1_OG2_EDV: unknown attribute .mId. Type 'attr UEST1_OG2_EDV ?' for a detailed list.\
KG_FS1_OA: unknown attribute .mId. Type 'attr KG_FS1_OA ?' for a detailed list.\
AB_GAO_FS1_SSPPWTI: unknown attribute .mId. Type 'attr AB_GAO_FS1_SSPPWTI ?' for a detailed list.\
OG1_KUE_FS1_OA: unknown attribute .mId. Type 'attr OG1_KUE_FS1_OA ?' for a detailed list.\
AB_GS_NM_RWS: unknown attribute .mId. Type 'attr AB_GS_NM_RWS ?' for a detailed list.\
AB_VG_BW: unknown attribute .mId. Type 'attr AB_VG_BW ?' for a detailed list.\
AB_SG_BW: unknown attribute .mId. Type 'attr AB_SG_BW ?' for a detailed list.\
OG2_B1_KG: unknown attribute .mId. Type 'attr OG2_B1_KG ?' for a detailed list.\
AB_FR_AAM: unknown attribute .mId. Type 'attr AB_FR_AAM ?' for a detailed list.\
EG_STH_AAM: unknown attribute .mId. Type 'attr EG_STH_AAM ?' for a detailed list.\
OG1_VR_AAM: unknown attribute .mId. Type 'attr OG1_VR_AAM ?' for a detailed list.\
OG2_BU1_AAM: unknown attribute .mId. Type 'attr OG2_BU1_AAM ?' for a detailed list.\
EG_BA_HZG_RT: unknown attribute .mId. Type 'attr EG_BA_HZG_RT ?' for a detailed list.\
EG_BA_HZG_TC: unknown attribute .mId. Type 'attr EG_BA_HZG_TC ?' for a detailed list.\
EG_KU_HZG_RT: unknown attribute .mId. Type 'attr EG_KU_HZG_RT ?' for a detailed list.\
EG_KU_HZG_TC: unknown attribute .mId. Type 'attr EG_KU_HZG_TC ?' for a detailed list.\
EG_SL_HZG_RT: unknown attribute .mId. Type 'attr EG_SL_HZG_RT ?' for a detailed list.\
EG_SL_HZG_TC: unknown attribute .mId. Type 'attr EG_SL_HZG_TC ?' for a detailed list.\
EG_STH_HZG_RT: unknown attribute .mId. Type 'attr EG_STH_HZG_RT ?' for a detailed list.\
EG_WC_HZG_RT: unknown attribute .mId. Type 'attr EG_WC_HZG_RT ?' for a detailed list.\
EG_WI_HZG_RT: unknown attribute .mId. Type 'attr EG_WI_HZG_RT ?' for a detailed list.\
EG_WZ_HZG_RT: unknown attribute .mId. Type 'attr EG_WZ_HZG_RT ?' for a detailed list.\
EG_WZ_HZG_TC: unknown attribute .mId. Type 'attr EG_WZ_HZG_TC ?' for a detailed list.\
OG1_KI_HZG_RT: unknown attribute .mId. Type 'attr OG1_KI_HZG_RT ?' for a detailed list.\
OG1_KI_HZG_TC: unknown attribute .mId. Type 'attr OG1_KI_HZG_TC ?' for a detailed list.\
OG1_KU_HZG_RT: unknown attribute .mId. Type 'attr OG1_KU_HZG_RT ?' for a detailed list.\
OG1_KU_HZG_TC: unknown attribute .mId. Type 'attr OG1_KU_HZG_TC ?' for a detailed list.\
OG1_SL_HZG_RT: unknown attribute .mId. Type 'attr OG1_SL_HZG_RT ?' for a detailed list.\
OG1_SL_HZG_TC: unknown attribute .mId. Type 'attr OG1_SL_HZG_TC ?' for a detailed list.\
OG1_STH_HZG_RT: unknown attribute .mId. Type 'attr OG1_STH_HZG_RT ?' for a detailed list.\
OG1_STH_HZG_TC_Weather_vt: unknown attribute .mId. Type 'attr OG1_STH_HZG_TC_Weather_vt ?' for a detailed list.\
OG1_WC_HZG_RT: unknown attribute .mId. Type 'attr OG1_WC_HZG_RT ?' for a detailed list.\
OG1_WC_HZG_TC_Weather_vt: unknown attribute .mId. Type 'attr OG1_WC_HZG_TC_Weather_vt ?' for a detailed list.\
OG1_WZ_HZG_RT: unknown attribute .mId. Type 'attr OG1_WZ_HZG_RT ?' for a detailed list.\
OG1_WZ_HZG_TC: unknown attribute .mId. Type 'attr OG1_WZ_HZG_TC ?' for a detailed list.\
OG2_BU1_HZG_RT: unknown attribute .mId. Type 'attr OG2_BU1_HZG_RT ?' for a detailed list.\
OG2_BU1_HZG_TC: unknown attribute .mId. Type 'attr OG2_BU1_HZG_TC ?' for a detailed list.\
OG2_BU2_HZG_RT1: unknown attribute .mId. Type 'attr OG2_BU2_HZG_RT1 ?' for a detailed list.\
OG2_BU2_HZG_RT2: unknown attribute .mId. Type 'attr OG2_BU2_HZG_RT2 ?' for a detailed list.\
OG2_BU2_HZG_TC: unknown attribute .mId. Type 'attr OG2_BU2_HZG_TC ?' for a detailed list.\
OG2_WC_HZG_RT: unknown attribute .mId. Type 'attr OG2_WC_HZG_RT ?' for a detailed list.\
EG_STH_T1_VR: unknown attribute .mId. Type 'attr EG_STH_T1_VR ?' for a detailed list.\
AB_SA_NT: unknown attribute .mId. Type 'attr AB_SA_NT ?' for a detailed list.\
EG_STH_T1_VG: unknown attribute .mId. Type 'attr EG_STH_T1_VG ?' for a detailed list.\
EG_STH_T1_FB: unknown attribute .mId. Type 'attr EG_STH_T1_FB ?' for a detailed list.\
AB_FR_RM: unknown attribute .mId. Type 'attr AB_FR_RM ?' for a detailed list.\
RM_TeamDev_ABFR: unknown attribute .mId. Type 'attr RM_TeamDev_ABFR ?' for a detailed list.\
AB_GAO_RM: unknown attribute .mId. Type 'attr AB_GAO_RM ?' for a detailed list.\
RM_TeamDev_ABGAO: unknown attribute .mId. Type 'attr RM_TeamDev_ABGAO ?' for a detailed list.\
RM_TeamDev_EG: unknown attribute .mId. Type 'attr RM_TeamDev_EG ?' for a detailed list.\
OG1_KI_RM: unknown attribute .mId. Type 'attr OG1_KI_RM ?' for a detailed list.\
OG1_KUE_RM: unknown attribute .mId. Type 'attr OG1_KUE_RM ?' for a detailed list.\
OG1_SL_RM: unknown attribute .mId. Type 'attr OG1_SL_RM ?' for a detailed list.\
OG1_VR_RM: unknown attribute .mId. Type 'attr OG1_VR_RM ?' for a detailed list.\
OG1_WZ_RM: unknown attribute .mId. Type 'attr OG1_WZ_RM ?' for a detailed list.\
RM_TeamDev_OG1: unknown attribute .mId. Type 'attr RM_TeamDev_OG1 ?' for a detailed list.\
OG2_BU1_RM: unknown attribute .mId. Type 'attr OG2_BU1_RM ?' for a detailed list.\
OG2_BU2_RM: unknown attribute .mId. Type 'attr OG2_BU2_RM ?' for a detailed list.\
OG2_EDV_RM: unknown attribute .mId. Type 'attr OG2_EDV_RM ?' for a detailed list.\
OG2_DB_RM: unknown attribute .mId. Type 'attr OG2_DB_RM ?' for a detailed list.\
OG2_VR_RM: unknown attribute .mId. Type 'attr OG2_VR_RM ?' for a detailed list.\
RM_TeamDev_OG2: unknown attribute .mId. Type 'attr RM_TeamDev_OG2 ?' for a detailed list.\
AB_GAO_BWS: unknown attribute .mId. Type 'attr AB_GAO_BWS ?' for a detailed list.\
AB_FR_AD: unknown attribute .mId. Type 'attr AB_FR_AD ?' for a detailed list.\
Mittlerweile Backup wieder eingespielt.
Hm. Noch unklar. Der Update funktioniert nur, wenn HMconfig aucn geladen ist. Und es sollte einen reboot geben. Ein update sollte das erreichen.
.mId wird von cul_hm eingetragen. Nach reboot.
Die fehlenden Kommandos deuten darauf hin, dass HMconfig fehlt oder kein reboot stattgefunden hat.
Hier nach Update völlig identische Fehlermeldungen.
Was ist mit Reboot gemeint? "shutdown restart sowie system reboot ändern nichts.
attribute die Fhem nicht mehr kennt, werden auch nicht mehr geladen, dafür landen sie im Logfile.
damit man sie beim nächsten Start nicht wieder lädt, --> sie stehen ja noch in der Fhem.conig drin
muß man wie schon immer -->einen save machen.
shutdown restart und alles sollte wieder supi sein.
Negativ. shutdown restart ändert nichts:
HM_5A6737: unknown attribute .mId. Type 'attr HM_5A6737 ?' for a detailed list.
(zig solche Meldungen, je Gerät eine Meldung)
Autosave deactivated
Zitateinen save machen
save in cmd
sace config als Knopf
Nach dem heutigen Update und shutdown+restart waren zunächst wieder für alle HomMatic Komponenten Meldungen im Log wie diese:
2019.01.10 08:13:37 3: Temp.Dach: unknown attribute .mId. Type 'attr Temp.Dach ?' for a detailed list.
Ich habe dann, nachdem fhem alle status requests durchgeführt hatte mit "Save config" und mit {WriteStatefile()} die entsprechenden Dateien gesichert. Nach dem Neustart sind keine Meldungen mehr vorhanden.
Hab es nun auch in den Griff bekommen. Backup zurück -> Update -> shutdown restart. Sieht wieder alles gut aus.
Hier auch.
P.S. Korrektur: Leider ganz und gar nicht.
Ich habe heute ein Update durchgeführt.
Bei den virtuellen Sensoren fehlt noch ein Attribut.
2019.01.11 10:35:20.229 3: set OG1_STH_HZG_TC_Weather_vT_S virtTemp 18.9 : Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet
2019.01.11 10:35:20.230 3: at_OG1_STH_HZG_TC_Weather_vt: Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet
2019.01.11 10:35:20.335 3: set OG1_WC_HZG_TC_Weather_vT_S virtTemp 18.2 : Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet
2019.01.11 10:35:20.336 3: at_OG1_WC_HZG_TC_Weather_vt: Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet
Der OG1_STH_HZG_TC_Weather_vT_S bekommt die richtige Temperatur übermittelt.
Die virtuelle Temperatur von OG1_WC_HZG_TC_Weather_vt wird trotz vorhandenem Peering nicht an den HM-CC-RT-DN übergeben.
Ebenso beim OG1_STH_HZG_TC_Weather.
list OG1_STH_HZG_TC_Weather_vT_S
Internals:
CFGFN /media/hdd/fhem/mycfg/HM/hm_rasp01.cfg
DEF AAA00101
NAME OG1_STH_HZG_TC_Weather_vT_S
NOTIFYDEV global
NR 3358
NTFY_ORDER 50-OG1_STH_HZG_TC_Weather_vT_S
STATE set_virtTemp 19.4
TYPE CUL_HM
chanNo 01
device OG1_STH_HZG_TC_Weather_vt
peerList EG_STH_HZG_RT_Weather,OG1_STH_HZG_RT_Weather,
READINGS:
2019-01-11 15:31:10 peerList EG_STH_HZG_RT_Weather,OG1_STH_HZG_RT_Weather,
2019-01-11 15:50:34 state set_virtTemp 19.4
2019-01-11 15:50:34 temperature 19.4
helper:
fkt virtThSens
virtTC 00
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
vd:
cmd 8470AAA001000000
idh 3212320
idl 256
msgCnt 8
msgRed 0
next 1547218349.21848
nextM 1547218349.21848
typ 2
val 00C2
vin 19.4
Attributes:
alias OG1 Stiegenhaus - Heizung - Raumtemperatur Weather
cyclicMsgOffset 250
group .Sensoren Temperatur Virtuell
icon temp_temperature
model VIRTUAL
peerIDs 00000000,613F9E01,6391C201,
room OG1-Stiegenhaus
sortby 03
webCmd press short:press long
Möglicher Weise hängt dieser Fehler am Attribut model VIRTUAL.
Bei der Durchsicht dieses Attribut gibt es keine Definition für Model mit VIRTUAL.
list OG1_STH_HZG_RT_Weather
Internals:
CFGFN /media/hdd/fhem/mycfg/HM/hm_rasp01.cfg
CHANGED
DEF 6391C201
NAME OG1_STH_HZG_RT_Weather
NOTIFYDEV global
NR 3343
NTFY_ORDER 50-OG1_STH_HZG_RT_Weather
STATE Raumtemperatur: 20.8 °C
TYPE CUL_HM
chanNo 01
device OG1_STH_HZG_RT
peerList OG1_STH_HZG_TC_Weather_vT_S,
READINGS:
2018-12-07 05:59:40 CommandAccepted no
2018-11-03 14:39:41 R-sign off
2018-12-17 20:08:29 RegL_01. 00:00 08:00
2019-01-11 15:50:29 measured-temp 20.8
2019-01-11 15:31:10 peerList OG1_STH_HZG_TC_Weather_vT_S,
2019-01-11 15:50:29 state 20.8
helper:
regLst ,1
expert:
def 1
det 1
raw 1
tpl 1
role:
chn 1
tmpl:
Attributes:
alias OG1 Stiegenhaus - Heizung - Raumthermostat Weather
devStateStyle style="text-align:left;;font-weight:bold;;"
event-on-change-reading .*
group OG1 Stiegenhaus - Heizung
icon hc_wht_regler
model HM-CC-RT-DN
peerIDs 00000000,AAA00101,
room Heizung,OG1-Stiegenhaus,_HM
sortby 05.04
stateFormat {sprintf(
"Raumtemperatur: %.1f °C",
ReadingsVal("$name","measured-temp",0))}
Zitat von: martinp876 am 08 Januar 2019, 21:53:37
Nun würde mich noch interessieren, wer sinnvoll beschreiben kann, was bei ihm passiert ist.
Nach dem Update gab es massiv der beschriebenen Fehlermeldung "HM_5A6737: unknown attribute .mId. Type 'attr HM_5A6737 ?' for a detailed list.". Außer dem unschönen "autosave deactivated" fiel mir erstmal nichts auf.
Nach einem weiteren Update kommt das nicht mehr. Allerdings werden nun meine Tür/Fenstermelder in FHEM überhaupt nicht mehr angezeigt. Als wenn sie nicht da wären. Kein Protokoll, kein SVG.
Bei mir sind alle diese Melder nicht in fhem.cfg. Sie werden via include aus einer weiteren Datei geladen.
Wenn man das so liest, sollte man wohl vorerst mal auf Updates verzichten, wenn man so wie ich einiges an Homematic hat.
Nein. Alles wieder in Ordnung.
Bei mir funktioniert soweit alles wieder, wie es sein soll. Ich bin dem Entwickler jedenfalls dankbar, dass er weiterhin Updates anbietet und sich kümmert, all die Probleme zu lösen. Ich finde es schon Wahnsinn, wie viel Zeilen Code in diesem Modul stecken.
Allerdings wird seit dem Update in meinen Fensterkontakten ein Channel angezeigt, der nun die gepeerten Devices führt. Das verstehe ich nicht?
Internals:
DEF 5D3DE9
IODev myHmUART
NAME Bad_Fenster
NOTIFYDEV global
NR 77
NTFY_ORDER 50-Bad_Fenster
STATE CMDs_done
TYPE CUL_HM
channel_01 Bad_Fenster_Win
Das hat auch zur Folge, dass der STATE nun nicht mehr direkt in den Internals des Device angezeigt wird sondern im neuen "channel_01 Bad_Fenster_Win"
Das ist bei allen bestehenden Fenster Kontakten. Bei einem heute neu hinzu gefügten Fensterkontakt ist das nicht der Fall und so, wie ich es von den anderen bisher kannte
Internals:
DEF 594C6E
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 15
NAME Kueche_Fenster
NOTIFYDEV global
NR 248
NTFY_ORDER 50-Kueche_Fenster
STATE closed
TYPE CUL_HM
Gibt es noch mehr Anwender bei denen das so ist? Wie soll es richtig sein?
Zitat von: FunkOdyssey am 11 Januar 2019, 22:32:43
Nein. Alles wieder in Ordnung.
D.h. man man kann wieder gefahrlos ein Update machen?
Bei mir funktioniert soweit alles wieder, wie es sein soll. Ich bin dem Entwickler jedenfalls dankbar, dass er weiterhin Updates anbietet und sich kümmert, all die Probleme zu lösen. Ich finde es schon Wahnsinn, wie viel Zeilen Code in diesem Modul stecken.
Allerdings wird seit dem Update in meinen Fensterkontakten ein Channel angezeigt, der nun die gepeerten Devices führt. Das verstehe ich nicht?
Internals:
DEF 5D3DE9
IODev myHmUART
NAME Bad_Fenster
NOTIFYDEV global
NR 77
NTFY_ORDER 50-Bad_Fenster
STATE CMDs_done
TYPE CUL_HM
channel_01 Bad_Fenster_Win
Das hat auch zur Folge, dass der STATE nun nicht mehr direkt in den Internals des Device angezeigt wird sondern im neuen "channel_01 Bad_Fenster_Win"
Das ist bei allen bestehenden Fenster Kontakten. Bei einem Heute neu hinzu gefügten Fensterkontakt ist das nicht der Fall und so, wie ich es von den anderen bisher kannte
Internals:
DEF 594C6E
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 15
NAME Kueche_Fenster
NOTIFYDEV global
NR 248
NTFY_ORDER 50-Kueche_Fenster
STATE closed
TYPE CUL_HM
Gibt es noch mehr Anwender bei denen das so ist? Wie soll es richtig sein?
@martinp876
Zitat von: martinp876 am 08 Januar 2019, 21:53:37
Zu den Devices: Man muss nichts neu Pairen, peeren, oder Register setzen. FHEM /CUL_HM setzt ohne User Kommando NIE diese Einstellungen.
Das ist mein Trostpflaster, ich hoffe das sehr. Im Moment aber ...
Zitat von: martinp876 am 08 Januar 2019, 21:53:37
Die alten Versionen sind wieder eingecheckt. Ein weiteres Update sollte funktionieren.
Betroffen sind 10_CUL_HM.pm und HMConfig.pm
Ich habe eine Komplettsicherung des Verzeichnisses /opt/fhem vom 2018-12-23. Dazu später.
Das eigentliche System ist völlig aktuell. Meine Tür/Fensterkontakte werden NICHT angezeigt und auch nicht von FTUI verarbeitet.
Ich habe 10_CUL_HM.pm und HMConfig.pm von der o.g. Sicherung eingespielt. Neustart. Keine Änderung. Update, beide werden geupdatet. Neustart. Keine Änderung.
Bei mir sind alle Kontakte in einer ReadingsGruop zusammengefasst, da fiel mir dann doch etwas auf:
model HASH(0x48b14f8)Ok, dann kann so einiges nicht funktionieren.
Ich kann gerne lists veröffentlichen, Kommandos ausführen. Mir bitte aber konkret schreiben, was ich tun soll (ich habe im Moment Angst, alles noch schlimmer zu machen - sooo firm bin ich nicht.).
@Curt: vielleicht ist dein Problem dasselbe wie von Udomatic!?
(Einen Beitrag über deinem)
Gruß, Joachim
@MadMax-FHEM
Ich kann die Frage nicht beantworten.
Ich habe -wie ich mit Schrecken sehe- auch einen Fensterkontakt, der "RESPONSE TIMEOUT:RegisterRead" sagt - obwohl er antwortet.
Ich kann gern alle Kontakte auflisten (gern als Anlage). Nur müsste mir bitte jemand genau sagen, was ich in die FHEM-Kommandozeile eingeben muss.
list Gerätename
Von beispielsweise dem mit dem Timeout...
...und dann hier in Code-Tags posten...
Gruß, Joachim
list Dachfenster (das ist der mit dem Timeout)
Internals:
CFGFN ./FHEM/z-include-fenster.cfg
DEF 578BD4
IODev SCC
LASTInputDev SCC
MSGCNT 2
NAME Bad_Dachfenster
NOTIFYDEV global
NR 62
NTFY_ORDER 50-Bad_Dachfenster
SCC_MSGCNT 2
SCC_RAWMSG A0C318641578BD4000000010C00::-75:SCC
SCC_RSSI -75
SCC_TIME 2019-01-11 22:57:04
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:31 - t:41 s:578BD4 d:000000 010C00
protLastRcv 2019-01-11 22:57:04
protRcv 2 last_at:2019-01-11 22:57:04
rssi_at_SCC cnt:2 min:-75 max:-69.5 avg:-72.25 lst:-75
READINGS:
2019-01-11 22:36:31 Activity alive
2018-12-15 23:27:09 CommandAccepted yes
2018-12-15 23:27:08 D-firmware 1.0
2019-01-10 11:19:08 D-serialNr OEQ0395024
2018-07-28 02:39:04 PairedTo 0xFF1312
2018-07-28 02:39:03 R-cyclicInfoMsg on
2018-07-28 02:39:03 R-eventDlyTime 0 s
2018-12-15 23:27:08 R-pairCentral set_0xFF1312
2018-07-28 02:39:03 R-sabotageMsg on
2018-07-28 02:39:03 R-sign on
2019-01-10 14:12:01 RegL_00.
2018-12-15 23:27:09 aesCommToDev ok
2018-12-15 23:27:09 aesKeyNbr 00
2019-01-09 02:03:13 alive yes
2019-01-09 02:03:13 battery ok
2019-01-09 02:03:13 contact closed (to VCCU)
2019-01-10 11:19:12 powerOn 2019-01-10 11:19:12
2019-01-11 22:27:39 recentStateType info
2019-01-09 02:03:13 sabotageError off
2019-01-10 11:19:38 state RESPONSE TIMEOUT:RegisterRead
2018-07-29 02:16:42 trigDst_FF1312 noConfig
2019-01-11 22:57:04 trigger_cnt 12
helper:
HM_CMDNR 49
mId
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +578BD4,00,00,00
nextSend 1547243824.26376
rxt 0
vccu VCCU
p:
578BD4
00
00
00
prefIO:
SCC
mRssi:
mNo 31
io:
SCC:
-73
-73
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_SCC:
avg -72.25
cnt 2
lst -75
max -69.5
min -75
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev SCC
IOgrp VCCU:SCC
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:fts_window_roof_open_2@red closed:fts_window_roof@green
expert 2_raw
firmware 1.0
fp_Hauptseite 376,651,1,structure_Fenster
model HASH(0x48b14f8)
peerIDs 00000000,
room Unsorted
serialNr OEQ0395024
subType 1
userattr Fenster_Status Fenster_Status_map structexclude
Du arbeitest mit "verteilter" Config!?
Zitat
CFGFN ./FHEM/z-include-fenster.cfg
Da weiß ich nicht, ob da immer alles so tut wie gewollt/gesollt...
...wozu das?
Manuell editieren soll man ja tunlichst nicht!?
Wozu also die Aufteilung...
Die Einträge sind eigenartig (widerspricht sich ein wenig: gepaired aber trotzdem set_).
Evtl. wegen dem Timeout?
Zitat
2018-07-28 02:39:04 PairedTo 0xFF1312
...
2018-12-15 23:27:08 R-pairCentral set_0xFF1312
Vielleicht mal noch mal getConfig und "Anlernknöpfchen" drücken...
Das kann nicht stimmen:
Zitat
model HASH(0x48b14f8)
Was für ein Typ ist es denn?
HM-SEC-SC-2
oder
HM-SEC-SCo
Wie ist denn deine readingsGroup definiert?
Oder gibt es da kein Problem bis auf die "komische" Anzeige bzgl. model?
Gruß, Joachim
Zitat von: MadMax-FHEM am 11 Januar 2019, 23:23:16
Du arbeitest mit "verteilter" Config!?
Da weiß ich nicht, ob da immer alles so tut wie gewollt/gesollt...
...wozu das?
Manuell editieren soll man ja tunlichst nicht!?
Wozu also die Aufteilung...
Ich habe, als sie fertig waren, alle ausgelagert. Ich kann die auch gern alle zurück ins Reich holen. Aber wir verzetteln uns.
Zitat von: MadMax-FHEM am 11 Januar 2019, 23:23:16
Die Einträge sind eigenartig (widerspricht sich ein wenig: gepaired aber trotzdem set_).
Evtl. wegen dem Timeout?
Das kann ich nicht beurteilen.
Vergleichsweise ein Sensor ohne diese Fehlermeldung:
Internals:
CFGFN ./FHEM/z-include-fenster.cfg
DEF 30D87D
IODev SCC
NAME Gaeste_Fenster_Strasse
NOTIFYDEV global
NR 69
NTFY_ORDER 50-Gaeste_Fenster_Strasse
STATE closed
TYPE CUL_HM
READINGS:
2019-01-11 22:36:31 Activity alive
2017-06-20 21:07:37 CommandAccepted yes
2018-07-28 02:06:49 D-firmware 2.4
2018-07-28 02:06:49 D-serialNr LEQ1091622
2018-07-28 02:06:49 PairedTo 0xFF1312
2018-07-28 02:06:49 R-cyclicInfoMsg off
2018-07-28 02:06:49 R-eventDlyTime 0 s
2018-07-28 02:06:49 R-pairCentral 0xFF1312
2018-07-28 02:06:49 R-sabotageMsg on
2018-07-28 02:06:49 R-sign off
2018-07-28 02:06:49 RegL_00. 02:01 09:00 0A:FF 0B:13 0C:12 10:01 14:06 00:00
2018-07-28 02:06:49 RegL_01. 08:00 20:60 21:00 22:64 30:06 00:00
2018-07-28 02:07:09 alive yes
2019-01-09 00:45:38 battery ok
2019-01-09 00:45:38 contact closed (to VCCU)
2017-07-28 23:50:38 powerOn 2017-07-28 23:50:38
2018-07-28 02:07:09 recentStateType info
2018-07-28 02:07:09 sabotageError off
2019-01-09 00:45:38 state closed
2018-07-29 02:17:49 trigDst_FF1312 noConfig
2019-01-11 13:21:37 trigger_cnt 127
helper:
HM_CMDNR 50
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +30D87D,00,00,00
rxt 0
vccu VCCU
p:
30D87D
00
00
00
prefIO:
SCC
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
tmpl:
Attributes:
Fenster_Status structure_Fenster
IODev SCC
IOgrp VCCU:SCC
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:fts_window_1w_tilt@red closed:fts_window_1w@green
expert 2_raw
firmware 2.4
fp_Hauptseite 376,651,1,structure_Fenster
model HASH(0x48b14f8)
peerIDs 00000000,
room Unsorted
serialNr LEQ1091622
subType 1
userattr Fenster_Status Fenster_Status_map structexclude
Zitat von: MadMax-FHEM am 11 Januar 2019, 23:23:16
Vielleicht mal noch mal getConfig und "Anlernknöpfchen" drücken...
Ich komme vom Fach, also nicht HM-Fach, sondern IT-Fach. Erste Regel: Wenn was schief geht, Nerven bewahren. NICHT wild rumklicken! Das macht alles nur noch schlimmer!
Neh Du, ich mache das im Moment lieber nicht.
Zitat von: MadMax-FHEM am 11 Januar 2019, 23:23:16
Das kann nicht stimmen:
model HASH(0x48b14f8)
Tritt bei sämtlichen Kontakten auf.
Zitat von: MadMax-FHEM am 11 Januar 2019, 23:23:16
Was für ein Typ ist es denn?
HM-SEC-SC-2
Viele davon. Sowie einmal der -wie heißt der- der mit der Lichtschranke. Der mit der Lichtschranke ist der, der den response-timeout wirft!
Nachtrag: Das ist ein HM-SEC-SCoZitat von: MadMax-FHEM am 11 Januar 2019, 23:23:16
Wie ist denn deine readingsGroup definiert?
Oder gibt es da kein Problem bis auf die "komische" Anzeige bzgl. model?
So hier - da geht selbstredend der Filter schief, wir haben ja kein model, nur einen hash ... woher auch immer der kommt:
define rdg_Fenster_Tueren readingsGroup .*:FILTER=model=HM-SEC-SC(.*):battery,sabotageError,state
attr rdg_Fenster_Tueren alias Fenster und Türen
attr rdg_Fenster_Tueren room 11 Fenster Tür,Unsorted
attr rdg_Fenster_Tueren valueIcon { 'state' => '%devStateIcon', 'sabotageError.on' => 'time_manual_mode@red', 'sabotageError.off' => 'security@green', 'battery.ok' => 'measure_battery_100@green', 'battery.low' => 'measure_battery_0@red' }
attr rdg_Fenster_Tueren valueStyle style="text-align:right"
Aber auch alle Anzeigen in FTUI gehen schief. Für jeden Kontakt so eine Definition. Die leider derzeit auch nicht tut - was ich so interpretiere, dass state nicht aktualisiert wird.
<div data-type="symbol"
data-device="Terrassentuer"
data-on-color="#A00000"
data-off-color="#00A000"
data-states='[open,closed]'
data-icon="ftui-window"
data-get-on="open"
data-get-off="closed"
class="bigger compressed-50">
</div>
P.S:
HM-SEC-SCo konkretisiert.
Zitat von: curt am 11 Januar 2019, 23:42:51
Ich habe, als sie fertig waren, alle ausgelagert. Ich kann die auch gern alle zurück ins Reich holen. Aber wir verzetteln uns.
Ja, war ja nur eine Frage/Feststellung und Anmerkung, dass eben bei verteilten cfgs auch gerne mal was nicht so läuft wie es soll/gedacht.
Bei vielen Dingen ist die Reihenfolge entscheidend: IODev VOR Device (eh klar) etc.
Zitat von: curt am 11 Januar 2019, 23:42:51
Ich komme vom Fach, also nicht HM-Fach, sondern IT-Fach. Erste Regel: Wenn was schief geht, Nerven bewahren. NICHT wild rumklicken! Das macht alles nur noch schlimmer!
Neh Du, ich mache das im Moment lieber nicht.
Tja dann lass es halt.
Aber wenn die notwendigen Infos nicht zurückgelesen werden (getConfig) dann wird der Zustand halt "halbseiden" bleiben...
Und: mal ein getConfig (wenn man [was ich getan habe] zusieht, dass keine msgPending sind) ist kein Problem...
...und hat nichts mit "wild rumklicken" zu tun...
Zitat von: curt am 11 Januar 2019, 23:42:51
Tritt bei sämtlichen Kontakten auf.
Viele davon. Sowie einmal der -wie heißt der- der mit der Lichtschranke. Der mit der Lichtschranke ist der, der den response-timeout wirft! Nachtrag: Das ist ein HM-SEC-SCo
So hier - da geht selbstredend der Filter schief, wir haben ja kein model, nur einen hash ... woher auch immer der kommt:
Tja woher das kommt weiß ich auch nicht...
...aber solange das model nicht passt wird vieles nicht so gehen wie es soll.
Und ja das mit der Lichtschranke ist der HM-SEC-SCo...
Bzgl. FTUI kann ich nichts sagen, nutze ich nicht und kenne ich daher gerade mal dem Namen nach ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 11 Januar 2019, 23:23:16
Vielleicht mal noch mal getConfig und "Anlernknöpfchen" drücken...
Danke erstens für den Hinweis und zweitens für das Mut-machen. Nach einer nächtlichen Turnstunde habe ich nun Muskelkater, aber so ganz langsam pendeln die sich wieder ein.
Falls noch was sein sollte, würde ich mich melden.
Danke sehr!
Moin,
heute Früh wieder mal ein Update gemacht...
configfile: VCCU: unknown attribute .mId. Type 'attr VCCU ?' for a detailed list.
Und noch 20 weitere...
Habe diese Woche schon 3 mal nach einem Fehlerhaften Update ein Backup wiedereingespielt.
Bei den ersten malen waren ganzen Geräte verschwunden oder auch nur einzelene Kanäle.
Soll das ernst gemeint sein, das ich mich vor jedem Update hier ins Forum bemühe um zu sehen ob jemand einen Fehler gemacht und ein anderer dies unschön bemerkt hat.
Kann so nicht euer ernst sein!!! >:(
Nur so als Idee.
Wie wäre es mit einem Info Device über Aktuelle Hinweiße von der "FHEM-Zentrale" an FHEM.
Soll heisen, bei solchen Problemen bekommt man vor einem Update einen Hinweiß - "Update Fehlerhaft, wenn möglich abwarten"
MFG Rico
PS: Backup wieder einspielen oder abwarten?
Ich fasse es noch einmal so zusammen
- technisch
# aktuell wird die Struktur der Entites aus dem Attribut "model" abgeleitet. Um mit Bugs von eQ3 umgehen zu können muss man das überschreiben können. "model" wird (leider) auch von anderen Modulen genutzt weshalb ich es nicht ändern kann. Somit wird das Attribut ".mId" eingeführt und automatisch befüllt. Das klappt vollautomatisch - allerdings nur bei einem reboot => "shutdown reboot".
# Mein Fehler war anzunehmen, dass bei einem "Update" ein auch ein Reboot durchgeführt wird.
# CUL_HM/HMInfo ändert NIE ohne Kommandos Register/peering/pairings. So lange man das nicht anstößt wird das System ohne Zentrale weiterlaufen (ein Grund warum ich möglichst viele Funktionen ohne Zentrale realisiere -> Ausfallsicherheit)
# wenn man kein Save macht dürfen auch keinen neuen Attribute (".mId") gespeichert werden und nach einem Reboot sollten diese nicht mehr vorhanden sein. Macht man ein Save ist das Attribut gespeichert - logisch.
- ein Kanal Devices
# Wie im Einsteigerdoc beschrieben wird ( im Gegensatz zu einer Sauberen Installation) Kanal und Device nicht getrennt. Das ist eine Vereinfachung (vielleicht). Der Anwender hat aber immer die Option, Kanal 01 anzulegen oder zu löschen um diesen Device und Kanal zu trennen oder zu kombinieren. Hierbei werden die Attribute und Readings nicht übernommen (wie auch). Readings werden sich automatisch wieder einstellen (getConfig, Statusmeldungen,...) und die Attribute (welche nicht Systembedingt sind) liegen beim Anwender.
=> wenn beim Update Device und Kanal getrennt wurden kannst du den Kanal 01 einfach löschen
=> dass der Kanat abgetrennt wurde sollte typisch nicht passieren - ich versuche das einmal zu simulieren
- Ablauf
# da nach dem Update kein Reboot durchgeführt wurde kam es zu den Problemen. Ein "shutdown reboot" hätte das Problem beheben müssen - und ich habe Meldungen, dass dies bei manchen so funktioniert hat. Wäre also ganz einfach... aber ich verstehe natürlich die Frustration.
# sollte ein Update automatisch NACH den update ein Save machen hat man natürlich ein"altes". Macht man nun den "update" auf die alte (jetzt aktuelle) Version macht es Sinn, das vom ersten Update gesicherte fhem.cfg einzukopieren.
=> ein Einspielen des alten Standes sollte kein Problem sein wenn man
+ einen neuen Update macht
+ das fhem.cfg for dem ersten Update rein-kopiert
+ einen shutdown restart macht
+ maximale Fehlermeldungen könnten Readings sein, welche nicht mehr passen. Diese würde ich inorieren.
- Nächster Update
# da ich mich leider nicht auf den restart verlassen kann muss ich wohl doch hässliche Abfragen einbauen. In jedem Fall werden die neuen Funktionen erst aktiv, wenn man einen reboot macht. Geht nicht anders.
Hallo Martin.
Danke das du dich so einsetzt!
Ich kann Dir in meinem Fall versichern das ich 100%tig ein shutdown/reboot durchgeführt habe.
Direkt danach wurde mir schon angezeigt das Kanäle gelöscht wurden und ab diesen Zeitpunkt ging auch kein HM Aktor mehr. Siehe mein vorheriger Beitrag.
Danke & Gruß
Daniel
Hallo, ich schliesse mich den Vorrednern an....heute nachmittag geupdatet, es geht bei meinen Rollos kein down,stop, level, pct mehr .....
Bitte anschauen.
Danke.
Zitat von: FunkOdyssey am 11 Januar 2019, 22:32:43
Nein. Alles wieder in Ordnung.
Aufgrund der massiven Probleme bei verschiedenen Usern, verbunden mit deren unterschiedlichen Kenntnissen & Fertigkeiten, finde ich derartige Beiträge absolut nicht sinnvoll.
Auch wenn ich selbst bisher nicht betroffen bin, da ich glücklicherweise vor dem Update im Forum geguckt habe, finde ich die Vorgehensweise Mist.
Habe den ganzen Thread verfolgt und mehrfach gelesen...
der aktuelle Stand ist mir trotzdem nicht klar; anderen geht es vermutlich ähnlich.
Das ist keine Kritik am Modul-Maintainer; jeder verdient sein Geld im Job und das hier ist Hobby.
Aber bei den Usern ist es doch vergleichbar; wenn plötzlich nix mehr geht und die Zeit fehlt, kommt Hektik auf; auch mit Backup.
IMHO fehlt FHEM da ein Krisenmanagement, um weitere User zu schützen, und den Modulmaintainern etwas Zeit zu verschaffen!
Beispiel bei mehreren Problemmeldungen...
- 1 angepinnter Beitrag mit Infos
- besser noch ein roter Hinweistext mit Link dazu (wie bei neuen Release)
= man findet das vielleicht ohne die blöde Sufu und es kommen nicht drölfzig neue Threads
- Modul-Update wird nicht mehr ausgeliefert
- ältere Version wird wieder ausgeliefert
- Extra-Thread mit neuer Version und Beta-Testern (siehe aktuell 59_Weather)
- toll wäre natürlich ein Hinweis im Update-Check
Das ist nur so eine Idee, aber es guckt nicht jeder vor'm Update ins Forum.
Und es wird bei anderen Meldungen/Fragen auch gern "gemäkelt", ob denn erstmal alles auf dem aktuellsten Stand ist.
Sorry, das musste jetzt erstmal raus. :-\
Zitat von: martinp876 am 12 Januar 2019, 08:51:45
- ein Kanal Devices
# Wie im Einsteigerdoc beschrieben wird ( im Gegensatz zu einer Sauberen Installation) Kanal und Device nicht getrennt. Das ist eine Vereinfachung (vielleicht). Der Anwender hat aber immer die Option, Kanal 01 anzulegen oder zu löschen um diesen Device und Kanal zu trennen oder zu kombinieren. Hierbei werden die Attribute und Readings nicht übernommen (wie auch). Readings werden sich automatisch wieder einstellen (getConfig, Statusmeldungen,...) und die Attribute (welche nicht Systembedingt sind) liegen beim Anwender.
=> wenn beim Update Device und Kanal getrennt wurden kannst du den Kanal 01 einfach löschen
=> dass der Kanat abgetrennt wurde sollte typisch nicht passieren - ich versuche das einmal zu simulieren
Danke für die ausführliche Erklärung. Wie von dir beschrieben konnte ich Kanal 01 bei den betreffenden Fenster Kontakten löschen und wieder zu einem Device zusammen führen.
Zitat von: Hollo am 12 Januar 2019, 17:15:47
Aufgrund der massiven Probleme bei verschiedenen Usern, verbunden mit deren unterschiedlichen Kenntnissen & Fertigkeiten, finde ich derartige Beiträge absolut nicht sinnvoll.
Auch wenn ich selbst bisher nicht betroffen bin, da ich glücklicherweise vor dem Update im Forum geguckt habe, finde ich die Vorgehensweise Mist.
Habe den ganzen Thread verfolgt und mehrfach gelesen...
der aktuelle Stand ist mir trotzdem nicht klar; anderen geht es vermutlich ähnlich.
Das ist keine Kritik am Modul-Maintainer; jeder verdient sein Geld im Job und das hier ist Hobby.
Aber bei den Usern ist es doch vergleichbar; wenn plötzlich nix mehr geht und die Zeit fehlt, kommt Hektik auf; auch mit Backup.
IMHO fehlt FHEM da ein Krisenmanagement, um weitere User zu schützen, und den Modulmaintainern etwas Zeit zu verschaffen!
Beispiel bei mehreren Problemmeldungen...
- 1 angepinnter Beitrag mit Infos
- besser noch ein roter Hinweistext mit Link dazu (wie bei neuen Release)
= man findet das vielleicht ohne die blöde Sufu und es kommen nicht drölfzig neue Threads
- Modul-Update wird nicht mehr ausgeliefert
- ältere Version wird wieder ausgeliefert
- Extra-Thread mit neuer Version und Beta-Testern (siehe aktuell 59_Weather)
- toll wäre natürlich ein Hinweis im Update-Check
Das ist nur so eine Idee, aber es guckt nicht jeder vor'm Update ins Forum.
Und es wird bei anderen Meldungen/Fragen auch gern "gemäkelt", ob denn erstmal alles auf dem aktuellsten Stand ist.
Sorry, das musste jetzt erstmal raus. :-\
hi das hatte ich schon vor vielen monden vorgeschlagen, wurde aber abgelehnt,
damals war es gefühlte 50 Threads, jetzt wenigstens nur 1 ner, also schon mal eine Verbesserung.
muss aber auch sagen, ich habe bei mir, durch die Meldungen noch kein update gemacht.
(nur Systeme mit HM) die anderen laufen gut.
gruss
Ich würde diese Initiative unterstützen.
Wenn ich nicht zufällig den Thread gelesen hätte, stände ich wahrscheinlich auch vor einem Problem, da ich regelmäßig FHEM-Updates mache.
Zitat von: martinp876 am 12 Januar 2019, 08:51:45
# Mein Fehler war anzunehmen, dass bei einem "Update" ein auch ein Reboot durchgeführt wird.
Zitat von: martinp876 am 12 Januar 2019, 08:51:45
# wenn man kein Save macht dürfen auch keinen neuen Attribute (".mId") gespeichert werden und nach einem Reboot sollten diese nicht mehr vorhanden sein. Macht man ein Save ist das Attribut gespeichert - logisch.
Du gehst im Moment von falschen Annahmen aus.
1) Ich mache GRUNDSÄTZLICH reboot nach update.
2) Danach (Home-Seite von FHEM im Browser, MOTD) waren diese Fehlermeldungen da - ich machte KEIN save.
Ich sehe im Moment die Gefahr, dass Du den/die Fehler beim Nutzer suchst. Das dürfte in diesem Fall zu einfach sein.
Hoffe geholfen zu haben.
Zitat von: martinp876 am 08 Januar 2019, 21:53:37
Sorry, für die misslungene Änderung. Ich hatte etliche updated reboots und restarts erfolgreiche getest.
Sorry, dass ich erst jetzt antworte : tagsüber muss ich Bröttchen verdienen.
Die alten Versionen sind wieder eingecheckt. Ein weiteres Update sollte funktionieren.
Betroffen sind 10_CUL_HM.pm und HMConfig.pm
Zu den Devices: Man muss nichts neu Pairen, peeren, oder Register setzen. FHEM /CUL_HM setzt ohne User Kommando NIE diese Einstellungen.
Zu den Configs: Wenn man ein Save macht bleiben alle Einstellungen erhalten. Readings konnten sich verändern.
Es würde also reichen, 10_CUL_HM.pm und HMConfig.pm wieder einzuspielen.
Nun würde mich noch interessieren, wer sinnvoll beschreiben kann, was bei ihm passiert ist. Ich habe auch Rachmelder und Teamleads - die sind sauber upgedated worden mit der neuen SW.
Die Änderungen werden kommen - und wenn ich die Probleme kenne, kann ich diese korrigieren und testen.
bspw: Das Attribut ".mId" ist in der neuen Version gültig, neu und ganz normal eingeführt. Es kann nicht zu Fehlermeldungen führen. Ist das der Fall brauche ich Details.
Hallo Martin,
ich hatte direkt am 06.01 das Update gemacht und keine Probleme nach dem Reboot gehabt.
Zwischendurch seit dem 06.01. ebenfalls mehrere Neustarts. Keine Problem.
Heute Morgen war mein FHEM irgendwie abgestürzt, also nichts bei gedacht und ein Neustart gemacht und anschließend hatte ich die hier im Thread beschriebenen Probleme.
Grüße
Oliver
Hallo,
folgender Fehler mit dem heutigen Update:
Ich nutze einen Außen-Universalsensor nach https://wiki.fhem.de/wiki/Universalsensor zur Helligkeits- und Temperaturmessung.
Der Sensor stand auf activity dead, zusätzlich wurde ein unbekanntes Gerät HM_E10B08 angelegt, das keine sinnvoll verwertbaren Informationen lieferte
Bin jetzt zurück auf eine Uralt-Version
Achim
Weiterentwicklungen sollen und müssen auch sein. Vielleicht sollte man aber mal das Update-Konzept überprüfen. Bei vielen Entwicklungen gibt es z.B. die Möglichkeit, beim Update zwischen ,,stable" und ,,development" wählen zu können.
Beispiel: bei Homematic würde ich immer auf stable zurückgreifen wollen, bei MQtt(2) aktuell auf development.
Das wäre auf jeden Fall besser als einzelne Module per exclude vom Update auszuschließen. Wer von den Anwendern weiß denn schon konkret, welche Module z.B. zu Homematic gehören. Bei dem aktuellen Problem hieß es ja auch zuerst, die Module 10_CUL_HM.pm und 00_HMLAN.pm wären die Verursacher. Mittlerweile wissen wir von Martin, dass es die Module 10_CUL_HM.pm und HMConfig.pm waren. Wer also nur die ersteren Module zurückgespielt hat, fuhr ein inkonsistentes System - mit welchen Auswirkungen auch immer.
Bei einem "update check" sehe ich zwar, welche Module seit meinem letzten Update geändert wurden. Es hilft mir aber nicht wirklich. Wenn unter anderem HMConfig.pm beteiligt war, müsste es doch auch in meinem restoreDir vom 06.01. vorhanden sein. Da ist es aber nicht.
LG
Holger
Moin,
hab gerade ein Update -natürlich mit reboot- in der Hoffnung gemacht, dass wirklich die alte Version wieder eingespielt wurde.
Mist! Das war überhaupt nichts!
Heute werden beim Start zwei neue Geräte angelegt und der Universalsensor, der über Jahre perfekt funktioniert hat, ist dead!
Ich werde eine alte Version wieder einspielen und CUL_HM vom update ausschließen.
Achim
Hier die Listings der Geräte:
HM_590026
Internals:
CFGFN
CUL_0_MSGCNT 10
CUL_0_RAWMSG A118B3400590026680000C2100872776636A7::-58.5:CUL_0
CUL_0_RSSI -58.5
CUL_0_TIME 2019-01-13 10:17:05
DEF 590026
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 10
NAME HM_590026
NOTIFYDEV global
NR 282
STATE ???
TYPE CUL_HM
lastMsg No:8B - t:00 s:590026 d:680000 C2100872776636A7
protLastRcv 2019-01-13 10:16:14
protRcv 1 last_at:2019-01-13 10:16:14
protRcvB 1 last_at:2019-01-13 10:16:14
rssi_at_CUL_0 cnt:10 min:-58.5 max:-58.5 avg:-58.5 lst:-58.5
.attraggr:
.attrminint:
READINGS:
2019-01-13 10:16:14 .D-devInfo -
2019-01-13 10:16:14 .D-stc -
2019-01-13 10:16:14 .protLastRcv 2019-01-13 10:16:14
2019-01-13 10:16:14 D-firmware 12.2
2019-01-13 10:16:14 D-serialNr rwf6�
helper:
HM_CMDNR 178
mId
supp_Pair_Rep 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +590026,00,00,00
nextSend 1547371025.65997
prefIO
rxt 0
vccu
p:
590026
00
00
00
mRssi:
mNo 8B
io:
CUL_0:
-52.5
-52.5
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL_0:
avg -58.5
cnt 10
lst -58.5
max -58.5
min -58.5
tmpl:
Attributes:
autoReadReg 4_reqStatus
expert 2_raw
firmware 12.2
model unknown
room CUL_HM
serialNr rwf6�
subType und
HM_C21008
Internals:
CFGFN
CUL_0_MSGCNT 28
CUL_0_RAWMSG A12700000C2100872715937A2705FB003FA10ED::-101.5:CUL_0
CUL_0_RSSI -101.5
CUL_0_TIME 2019-01-13 10:20:17
DEF C21008
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 28
NAME HM_C21008
NOTIFYDEV global
NR 280
STATE ???
TYPE CUL_HM
lastMsg No:70 - t:00 s:C21008 d:727159 37A2705FB003FA10ED
protLastRcv 2019-01-13 10:16:14
protRcv 1 last_at:2019-01-13 10:16:14
rssi_at_CUL_0 cnt:28 min:-101.5 max:-101.5 avg:-101.5 lst:-101.5
.attraggr:
.attrminint:
READINGS:
2019-01-13 10:16:14 .D-devInfo -
2019-01-13 10:16:14 .D-stc -
2019-01-13 10:16:14 .protLastRcv 2019-01-13 10:16:14
2019-01-13 10:16:14 D-firmware 3.7
2019-01-13 10:16:14 D-serialNr _���
helper:
HM_CMDNR 151
mId
supp_Pair_Rep 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +C21008,00,00,00
nextSend 1547371217.65453
prefIO
rxt 0
vccu
p:
C21008
00
00
00
mRssi:
mNo 70
io:
CUL_0:
-99.5
-99.5
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL_0:
avg -101.5
cnt 28
lst -101.5
max -101.5
min -101.5
tmpl:
Attributes:
autoReadReg 4_reqStatus
expert 2_raw
firmware 3.7
model unknown
room CUL_HM
serialNr _���
subType
Hallo,
ich habe mein SQL-Backup und FHEM-Backup vom 31.12.18 vorgekramt, geht wieder....
Ja ist ärgerlich solch Fehler....aber was solls.... Habe meiner Frau damit den Unabhängigkeitstest von FHEM (bei zb Stromausfall) bewiesen.... die Hütte war zumindest bei diesem Ausfall noch warm... ;D
Es zeigt wieder, dass Backups unverzichtbar sind.... und auch diese mal getestet werden müssen/sollen.
So, schönes Rest WE!!!
Zitat von: Omega am 13 Januar 2019, 10:23:10
Weiterentwicklungen sollen und müssen auch sein. Vielleicht sollte man aber mal das Update-Konzept überprüfen. Bei vielen Entwicklungen gibt es z.B. die Möglichkeit, beim Update zwischen ,,stable" und ,,development" wählen zu können.
Beispiel: bei Homematic würde ich immer auf stable zurückgreifen wollen, bei MQtt(2) aktuell auf development.
Ceterum censeo: Umstellung auf ein Plugin-Modell, bei dem die einzelnen Module nicht per default dabei sind, sondern über einen Plugin Manager nachinstalliert werden können. Jeder User könnte - wie beim Debian-Modell - stable, oldstable, testing, etc. wählen, was auch immer besser zu seinem Setup passt. Der aktuelle update-Mechanismus ist viel zu grob um eine stabile Plattform ermöglichen zu können.
Just my 0.02€
Zitat von: Christoph Morrison am 13 Januar 2019, 12:08:55
Ceterum censeo: Umstellung auf ein Plugin-Modell, bei dem die einzelnen Module nicht per default dabei sind, sondern über einen Plugin Manager nachinstalliert werden können. Jeder User könnte - wie beim Debian-Modell - stable, oldstable, testing, etc. wählen, was auch immer besser zu seinem Setup passt. Der aktuelle update-Mechanismus ist viel zu grob um eine stabile Plattform ermöglichen zu können.
Just my 0.02€
Ein Update-Manager finde sehr gut. Ich würde aber nicht nur Update Channel sondern auch gerne Versionen sehen. Jedes Module eine eigene Version. Wobei zur Vereinfachung Version auch ein Git Hash sein kann. Dann könnte es auch einen Roleback knopf geben, wo man direkt zur vorherigen Version springen kann. Außerdem könnte man die Änderungen aus der GIT History holen, als Dokumentation der Änderungen. Und eine Auswahl zwischen auto-update und manual-update.
Hallo,
ich bin auch dafür, dass nicht alle Module im FHEM Ordner sein sollten, alle werden immer mit aktualisiert, obwohl sie nicht im Einsatz sind.
An der Stelle auch eine Idee: Lassen sich in der FHEM Reference nicht die Module mit "Alphabet-Reitern" sortieren?
Eine unendliche Menge sind da mittlerweile verfügbar, und dadurch ist die Übersichtlichkeit nicht mehr so toll.
Danke.
Zitat von: oldscout am 13 Januar 2019, 17:01:49
ich bin auch dafür, dass nicht alle Module im FHEM Ordner sein sollten, alle werden immer mit aktualisiert, obwohl sie nicht im Einsatz sind.
Und dann beschließt du irgendwann ein neues Modul zum ersten Mal benutzen zu wollen und lädst dann (bzw. fhem) eine total veraltete nicht kompatible Version des Moduls...
Das ist bestimmt besser... ;)
Aber langsam sollte (wenn überhaupt) wohl ein eigener Thread bzgl. Update-Strategie, -Problematik, -... eröffnet werden...
Gruß, Joachim
Hi,
1) also einenUpdate-Manager müsst ihr im allgemeinen Forum beantragen. CUL_HM und die anderen Module machen das nicht. In diesem Forum wird es also nicht fruchten.
1a) Jeden Modul hat eine eigene Version - schon jetzt. Kann man sehen und aus SVN zurückholen.
1b) einzelne Module vom User zu maintainen halte ich für ambitioniert. Module haben Abhängigkeiten. CUL_HM ist weit unten in der Architektur, hat also wenige, bspw zu HMConfig. HMInfo hat zu CUL_HM und zu HMConfig. HMtemplate natürlich zu HMInfo. HMLan hat auch ein paar Abhängigkeiten. Wegen mir könnt ihr euer Glück versuchen. Typisch verwendet man hier allerdings eher Build labels..... Ich will das bei mir nicht einzeln maintainen.
2) der aktuelle Stand ist identisch zu dem vor dem 1.6.. Das zeigt der SVN vergleich. Wenn man also diesen zusammen mit den configs zu diesem Zeitpunkt einspielt müsste alles beim Alten sein.
3) HMConfig habe ich heute erneuert. Das darf keine Schwierigkeiten machen, sind interne Angelegenheiten.
4) @curt: danke für die Info. Leider kann ich es nicht nachvollziehen. Ich haben eine Config nach "alter Schule" (ohne ".mId") und mache reboots. Dann sind alle Kommando da. Ich suche die Fehler nicht beim Nutzer, ich suche den Fehler/das Szenario.
4a) was waren deine Fehlerleldungen? In der Vorrede sehe ich ausschliesslich "attr .mId unbekannt". Nach einem Reboot damals verstehe ich das nicht. Jetzt (heute) ist es klar - wir hatten einen Roleback.
5) @ Octek0815: verstehe ich auch nicht. Das system war am laufen, du hattest schon einen reboot - korrekt? nun kein Update mehr aber ein neuer Reboot - Jetzt hast du Probleme. Auch nur das fehlende .mId oder etwas anderes?
6) @awel: wie waren die Sensoren vor den Update definiert? Das Attr "Model" fehlt, CUL_HM weiss also nicht, um was es sich handelt. Wenn deine Config nicht überschrieben ist, oder du noch eine alte hast, sollte es nachvollziehbar sein. Wenn du einmal config drückst würden CUL_HM auch wieder alles eintragen.
7) @oldscout: auf welcher Version warst du? Hat du ein List eines der Rollos?
Ich habe vorhin ein update gemacht, und muss nun leider feststellen, dass es auch mein System irgendwie zerschossen hat.
Meine Tür und Fensterkontakt werden nicht mehr korrekt erkannt. Dadurch kann ich auch kein peerChan mehr absetzen.
Ist es Sinn jetzt für jeden Senor model und subtype von Hand einzustellen? Ist das Problem damit gelöst?
//EDIT: Ein getConfig scheint das Problem zu beheben. (Siehe Punkt 6 im vorigen Post)
Bekomme nun allerdings häufig RESPONSE TIMEOUT:RegisterRead - ob das damit zsammen hängt weiss ich nicht.
Hi, bin mir nicht sicher ob folgender Fehler bereit bekannt ist.
Ich habe virtuelle Temperatur Sensoren die sich nicht mehr aktualisieren lassen, da der Set Befehl dazu nicht mehr bekannt ist.
Ein getConfig hat da nicht geholfen:
Internals:
CFGFN /opt/fhem/cfg/fhem_2_umgebungsensoren.cfg
DEF 100201
IODev HMUART
NAME wz.vTmp1
NOTIFYDEV global
NR 116
NTFY_ORDER 50-wz.vTmp1
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 wz.vTmp1_Sensor1
channel_02 wz.vTmp1_Btn2
channel_03 wz.vTmp1_Btn3
channel_04 wz.vTmp1_Btn4
protCmdDel 3
protResnd 9 last_at:2019-01-13 18:07:05
protResndFail 3 last_at:2019-01-13 18:07:09
protSnd 3 last_at:2019-01-13 18:06:51
protState CMDs_done_Errors:1
READINGS:
2019-01-13 18:07:09 state RESPONSE TIMEOUT:RegisterRead
RegL_00.:
VAL
helper:
HM_CMDNR 250
cSnd 01272F5B10020100040000000000,01272F5B10020100040000000000
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +100201,00,02,00
prefIO
rxt 0
vccu VCCU
p:
100201
00
02
00
mRssi:
mNo
io:
HMLAN1:
HMUART:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev HMLAN1
IOgrp VCCU
autoReadReg 4_reqStatus
expert 2_raw
model VIRTUAL
verbose 5
webCmd virtual
Internals:
CFGFN /opt/fhem/cfg/fhem_2_umgebungsensoren.cfg
DEF 10020101
NAME wz.vTmp1_Sensor1
NOTIFYDEV global
NR 117
NTFY_ORDER 50-wz.vTmp1_Sensor1
STATE set_virtTemp 21.8
TYPE CUL_HM
chanNo 01
device wz.vTmp1
peerList wz.Heizung_Weather,
READINGS:
2018-12-23 00:21:56 humidity 0
2019-01-13 17:28:39 peerList wz.Heizung_Weather,
2019-01-08 22:34:47 state set_virtTemp 21.8
2019-01-08 22:34:47 temperature 21.8
helper:
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
shadowReg:
tmpl:
Attributes:
model VIRTUAL
peerIDs 38989B01,
room Wohnzimmer
Zitat//EDIT: Ein getConfig scheint das Problem zu beheben. (Siehe Punkt 6 im vorigen Post)
falsch interpretiert.
du sollst das knöpfchen am device entsprechend drücken ("config drückst"), um eine anlernmessage auszulösen, denn nur dort steht die model id drin. kein "set getconfig".
:) danke! funzt
Ich fasse zusammen:
Nach dem Update hatte ich Fehlermeldungen bzgl attr .mid
Nach einem Reboot des Systems waren die Fehlermeldungen weg, -> Die "typen" bzw. "model" der einzelnen Geräte wurden aber nicht erkannt.
Ein drücken des config-Taster am Gerät behebt das Problem.
@Sidey
schau nach Model und subType attr
bei deinem virtuellen Sensor
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat)
@martinp876
Zitat von: martinp876 am 13 Januar 2019, 17:25:35
4) @curt: danke für die Info. Leider kann ich es nicht nachvollziehen. Ich haben eine Config nach "alter Schule" (ohne ".mId") und mache reboots. Dann sind alle Kommando da.
4a) was waren deine Fehlerleldungen? In der Vorrede sehe ich ausschliesslich "attr .mId unbekannt". Nach einem Reboot damals verstehe ich das nicht. Jetzt (heute) ist es klar - wir hatten einen Roleback.
Ich beschreibe nochmals so genau wie möglich:
Ich habe HM-SEC-*
Wohl am 09.01. am sehr frühen Morgen
* update check
* update
* shutdown restart
(
kein Save in meiner Erinnerung im Spiel!
Ergebnis:* Im Browser Klick auf "Home". In MOTD (message of the day) werden ALLE HM-SEC-* wie folgt aufgelistet:
** "HM_xxxxxx: unknown attribute .mId. Type 'attr HM_xxxxxx ?'
Mein Gedanke: Oh, unschön. Kann man nichts machen, wird sich aufklären. Mal abwarten und beobachten.
Einen Tag später bemerke ich (den folgenden Fehler bemerkte ich erst dann), dass in meiner FTUI-Oberfläche mein Fester des Arbeitszimmers nicht korrekt angezeigt wird. Am Abend dann genauer angesehen:
* Im FHEM-Raum habe ich eine ReadingsGroup über alle Tür/Fensteröffner - die war komplett leer. Huch? Logfile, was weißt Du? "trigger_cnt: xx" und "alive" kommt noch, sonst aber nichts. Boah, was das denn?
* JEDE HM-SEC-* hatte das attr "model" so gesetzt -> model HASH(0x48b14f8) [Werte unterschiedlich]
* HM-SEC-SCo zusätzlich im STATE "RESPONSE TIMEOUT:RegisterRead" / HM-SEC-SC-2 keine weiteren Besonderheiten.
Ok, wozu habe ich Vollsicherungen?FHEM shutdown. Die beiden genannten *.pm mit Stand vom 23.12. zurückgeschrieben. Als debian-root: reboot.
* Zustand unverändert.
* hm update.
* Zustand unverändert.
* Forum sagt "nun wieder das update fahren!". Ok:
** update
** shutdown restart
(
kein Save in meiner Erinnerung im Spiel!
Prüfen.
* Zustand unverändert.
Anfrage hier im Thread. @MadMax-FHEM hilft mir auf das Pferd:
* set VCCU hmPairForSec 60
* zum Sensor rennen, Knopf drücken
* zurückrennen: set getconfig (dieses Sensors)
* zum Sensor rennen, Knopf drücken
* GoTo1 (für alle Sensoren)
* freuen, alles wieder gut. @MadMax-FHEM danke sagen.
Hoffe geholfen zu haben. Nachfragen - gern.
P.S: @all
Updatemanagement, meine Sicht in gebotener Kürze:
1) Das ist ein Hobbyprojekt, das muss man alles auch leisten können.
2) Bei vielen Modulen WILL man ja gerade die neuesten Updates!
3) Einzig sinnvoller Vorschlag scheint mir: Sofortiges Zurückziehen des fehlerhaften Updates, Fehlerthread aufmachen, Beta-Test-Thread aufmachen.
1Ct.
@ Sidney: Das Attr "model" steht bei dir auf "VIRTUAL" - was in der neuen Konfiguraiton relevant wird. Das ist also noch etwas aus einem Zwischen-update. Irgend etwas hast du nicht sauber zurück geführt.
@Curt: vielleicht war es zu früh. Die Korrekte Version wäre 18184
@Curt b): wenn das Device eine Config message sendet (kann man durch die Config-Taste am Device auslösen) wird CUL_HM das verarbeiten. Pairen ist nicht erforderlich! also keine Aktion (hmPairForSec....)
@all:
- die neue Version HMConfig ist online - morgen im update, heute im Anhang. Ist gefahrlos, da keine reconfig durchgeführt wird.
- eine neue Version von CL_HM ist im Anhang, nicht online.
=> ich empfehle einen manuellen Update zum Testen
1) beide Dateien downloaden / einspielen
2) shutdown restart ausführen
3) im Fehlerfall die beiden alten Dateien wieder einspielen und ein shutdown restart. Da kein save stattgefunden hat ist wieder alles beim Alten
Meine Tests
- VCCU erfolgreich
- Virtuelle Devices und Channels funktionieren
- Rollos funktionieren
- Heizung funktioniert
- Grafik funktioniert
- ich habe im gesamten Verlauf NIE ein device neu gepeert/gepairt oder register umgeschrieben
Zitat von: curt am 13 Januar 2019, 18:38:13
[...]
(kein Save in meiner Erinnerung im Spiel!)
[...]
(kein Save in meiner Erinnerung im Spiel!)
Wird das save ggf automatisch beim Update (und
vor dem shutdown restart) durchgeführt?
Zumindest bei einem weiteren shutdown restart wird das ja dann zwangsweise gespeichert, oder?
Anbei ein Log-Auszug vom Update heute (Markierung hab ich hinzugefügt):
2019.01.13 09:28:11 1: fhem
2019.01.13 09:28:11 1: UPD ./CHANGED
2019.01.13 09:28:11 1: UPD ./MAINTAINER.txt
2019.01.13 09:28:11 1: UPD FHEM/10_MQTT_GENERIC_BRIDGE.pm
2019.01.13 09:28:11 1: UPD FHEM/39_alexa.pm
2019.01.13 09:28:11 1: UPD FHEM/59_Weather.pm
2019.01.13 09:28:11 1: UPD FHEM/92_FileLog.pm
2019.01.13 09:28:11 1: UPD FHEM/DarkSkyAPI.pm
2019.01.13 09:28:11 1: UPD FHEM/OpenWeatherMapAPI.pm
2019.01.13 09:28:12 1: saving fhem.cfg <=================
2019.01.13 09:28:12 1: saving ./log/fhem.save <=================
2019.01.13 09:28:12 1:
2019.01.13 09:28:12 1: New entries in the CHANGED file:
2019.01.13 09:28:12 1: - feature: 39_alexa.pm: added support autostart of alexa-fhem
2019.01.13 09:28:12 1: added support for pubic FHEM Connector skill
2019.01.13 09:28:12 1: - change: 59_Weather completely reworked
Zitat von: martinp876 am 13 Januar 2019, 19:16:13
@Curt: vielleicht war es zu früh. Die Korrekte Version wäre 18184
@Curt b): wenn das Device eine Config message sendet (kann man durch die Config-Taste am Device auslösen) wird CUL_HM das verarbeiten. Pairen ist nicht erforderlich! also keine Aktion (hmPairForSec....)
Das mag alles so sein. In meiner Verunsicherung habe ich es halt so gemacht. Schau mal: Ich habe mir das alles eigentlich nur wegen "habe ich alle Fenster geschlossen?" angeschafft (alles andere kam mit Freude später). Also ist mir wichtig, dass Türen und Fenster auch wirklich gemeldet werden.
Die neuerliche umfangreiche Auflistung habe ich gemacht, weil Du mich darum gebeten hast. Nur aus diesem Grund. (Falls Du oder irgendwer nun einen Vorwurf herausliest - da ist KEIN Vorwurf. Mir ist sehr wohl klar, was FHEM ist - und ich bin da auch sehr dankbar.)
P.S - kam dazwischen:
@yersinia Meine Anmerkungen bezogen sich auf mein Vorgehen. Hier konkret: Händische, von mir gewollt ausgelöste Handlungen. Vielleicht insofern missverständlich formuliert.
Hi martinp876,
Update: Läuft nach einem kompletten Neustart wieder.
ich habe noch das Problem, dass der Fenstertürgriff (HM-SEC-RHS) nicht funktioniert.
Besteht immer noch:
Zudem bekomme ich noch folgende Meldung im Log (unabhängig vom anderen Problem):
PERL WARNING: Use of uninitialized value in hash element at /opt/fhem//FHEM/10_CUL_HM.pm line 7677.
Vielleicht hilft es ja.
Viele Grüße
Dennis
Zitat von: curt am 13 Januar 2019, 19:51:02
@yersinia Meine Anmerkungen bezogen sich auf mein Vorgehen. Hier konkret: Händische, von mir gewollt ausgelöste Handlungen. Vielleicht insofern missverständlich formuliert.
Für mich nicht missverständlich, hab das genauso interpretiert wie geschrieben. :)
Ich frag mich nur, ob das Update dann automatisch ein save durchführt und damit eventuell bei dem ein oder anderen etwas zerlegt. :/
Was bei dem meisten Update vernünftig zu sein scheint, kann in ~1% aller Fälle die Config zerstören....ist allerdings nur eine
Vermutung.
Ich bin froh, dass man den vor-Update-Stand wiederherstellen kann, und das ist auch recht gut dokumentiert.
Und für FOSS funktioniert FHEM für einen bleeding Anfänger mMn sehr gut und ist einfach zu bedienen.
ZitatIch frag mich nur, ob das Update dann automatisch ein save durchführt
Nein!
Es wird deine vorhandene fhem.cfg kopiert nach /opt/fhem/restoreDir....
bevor immer neue Vermutungen aufgestellt werden, könnte man es auch mal testen...
Hallo zusammen,
ich bin wieder auf die Version 10_CUL_HM 18170 und HMConfig 18171 zurückgegangen.
Hatte massive Probleme mit "Missing Acks" seit dem Update heute.
Im Einsatz Busware SCC.
Viele Grüße
Dennis
@krannich
Zitat von: krannich am 13 Januar 2019, 23:33:06
Hatte massive Probleme mit "Missing Acks" seit dem Update heute.
Das ist hier aber schon eine Mitmach-Veranstaltung. Dem Maintainer @martinp876 würde vermutlich sehr helfen, wenn Du das nicht allgemein schreibst, sondern konkret mit Logauszügen, lists usw. zeigen würdest.
leicht OT.
Zitat von: fhem-hm-knecht am 13 Januar 2019, 20:24:04
ZitatIch frag mich nur, ob das Update dann automatisch ein save durchführt
Nein!
Der Weg zur Hölle ist mit starken Sprüchen gepflastert.
Ich zeige Dir mal ein Beispiel, wie man das unabsichtlich eine Stunde später hinkriegt: @rudolfkoenig hatte man ganz nebenbei [es ging um Benzinpreise] gezeigt, wie man die Sortierung mehrerer Tankstellen an Hand des aktuellen Preises baut. Das bedeutet aber auch, dass FHEM immer mal rumquengelt, dass die veränderte conf zu speichern sei. Da klicke ich quasi blind drauf.
Anderes Beispiel:
Vermittels
define Lichterkette_an1 at *{sunset(0,"15:00","21:00")} set Stecker_02 on
define Lichterkette_aus1 at *00:18:00 set Stecker_02 offlasse ich automatisch mehrere Dinge schalten.
Die "on"-Konstruktion frisst irgendwer stochastisch aus der fhem.cfg. Ich habe nicht die geringste Ahnung, wer das ist, was da passiert. (In diesem Thread führt das zu weit - aber hab mal bitte eine Idee, wie ich das denn nun wieder debugge.)
Ich erwähne das, weil es sehr wohl mehrere Optionen gibt, die fhem.cfg zu schreiben. Die erste ist, es aus fachlich anderen Gründen zu tun; die HM-Änderung ist dann Seiteneffekt. Die zweite ist magisches Zaubersalz.
Zur Info: Mit dem heutigen Update
2019.01.14 08:35:11 1: UPD FHEM/HMConfig.pm
taucht die die folgende Fehlermeldung auf:
2019.01.14 08:35:51 1: PERL WARNING: Useless use of a variable in void context at FHEM/HMConfig.pm line 339, <$fh> line 308.
Alle Geräte funktionieren einwandfrei.
MfG
Achim
ZitatCode: [Auswählen]
Autor: curt
define Lichterkette_an1 at *{sunset(0,"15:00","21:00")} set Stecker_02 on
define Lichterkette_aus1 at *00:18:00 set Stecker_02 off
lasse ich automatisch mehrere Dinge schalten.
Die "on"-Konstruktion frisst irgendwer stochastisch aus der fhem.cfg. Ich habe nicht die geringste Ahnung, wer das ist, was da passiert. (In diesem Thread führt das zu weit - aber hab mal bitte eine Idee, wie ich das denn nun wieder debugge.)
wahrscheinlich (sicher) hast du den at 1 malig angelegt und dadurch steht er in der fhem.save drinn.
und nachträglich auf wiederkehrend geändert (*)
normales verhalten.
den saveconfig Knopf kann man auch abschalten, mir ist es auch 1 mal passiert dass ich im falschen Moment draufgedrückt habe.
Das mit dem Save nach dem update könnt ihr einfach testen, wie fhem-hm-knecht beschrieben hat.
Ebenso kann man das fhem.cfg wieder einkopieren
Die Meldung aus HMconfig ist berechtigt aber absolut gefahrlos.
Die Meldung Zeile /opt/fhem//FHEM/10_CUL_HM.pm line 7677 sollte auch nichts machen. Du kannst aber einmal ein
get hm param -d model subType mId .mId
schicken. (attachement wäre sinnvoll). Jedes Device sollte ein Model, SubType und mId haben. Die .mId ist neu.
Nun wüden mich noch die missingacks interessieren. Ich haben keine, sonst hätte ich nicht gepostet - klar. Welche Devices? welches IO? Ist IODef oder die vccu korrekt eingestellt?
Hallo Zusammen,
ich habe auch auf meinem Raspberry einen Busware SCC mit Homematic Geräten laufen.
Nach meinem Update sind alle Homematic Geräte nicht mehr gepaired bzw. lassen sich nicht mehr ansprechen.
Wenn ich ich erneut "set hmpairForSec" 120 tätige und bei meinen Geräten den "Config Schalter" drücke werden alle wieder gepaired und man kann die Geräte über FHEM ansprechen.
Wenn man aber FHEM durchstartet und die Geräte erneut steuern möchte, bekommt immer noch die Fehlermeldung am Beispiel der Rolladensteuerung angezeigt.
Unknown argument down, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet templateDel
Irgendwie hält FHEM das PAIRING nicht
Muss man bei den Homematic Geräten neue Attributen mitgeben aufgrund des Updates?
Hat jemand einen Tip?
Gruss,
Markus
Wir sind mit diesem Beitrag schwer offtopic. Bitte ggf. auslagern!
Zitat von: fhem-hm-knecht am 14 Januar 2019, 09:00:18
Zitat
define Lichterkette_an1 at *{sunset(0,"15:00","21:00")} set Stecker_02 on
define Lichterkette_aus1 at *00:18:00 set Stecker_02 off
Die "on"-Konstruktion frisst irgendwer stochastisch aus der fhem.cfg. Ich habe nicht die geringste Ahnung, wer das ist, was da passiert. (In diesem Thread führt das zu weit - aber hab mal bitte eine Idee, wie ich das denn nun wieder debugge.)
wahrscheinlich (sicher) hast du den at 1 malig angelegt und dadurch steht er in der fhem.save drinn.
und nachträglich auf wiederkehrend geändert (*)
normales verhalten.
Nein.
Es gibt drei derartige Konstruktionen. Die habe ich aus dem Wiki abgeschrieben und in fhem.cfg reingeworden, vor über einem Jahr. (Jaja, sag nix. Nie fhem.cfg anfassen.) Die taten mehr als ein Jahr richtig gut.
Seit -ich weiß nicht- einer Woche wird immer mal wieder der erste Eintrag (anschalten) in fhem.cfg weggefressen. Ja klar, dadurch, dass ich speichere.
Hab bitte lieber eine Idee, wie ich den Verursacher der Löscherei ausfindig mache. Das kann so ja nicht bleiben.
Ich habe heute auch ein Update durchgeführt mit folgendem Ergebnis:
Nach dem ,,shutdown restart" hatte ich für jedes HM-Device die Meldung ,,unknown attribute .mId." im Log.
Daraufhin habe ich ein ,,save" ausgeführt und noch einmal einen ,,shutdown restart".
Die Meldungen ,,unknown attribute .mId." waren jetzt verschwunden.
Ein configCheck bring jetzt allerdings erstmalig Fehlermeldungen bzgl. meiner Rauchmelderteams
PairedTo missing/unknown
Rauchmelder
Rauchmelder_2
Ich habe jetzt einfach mal ein
get hm param -d model subType mId .mId
durchgeführt mit folgendem Ergebnis:
entity : model | subType | mId | .mId
...
OG.Naehen.Wandthermostat : HM-TC-IT-WM-W-EU | thermostat | 00AD | -
RM_Dachboden : HM-SEC-SD | smokeDetector | 0042 | -
RM_Flur_OG : HM-SEC-SD | smokeDetector | 0042 | -
RM_Flur_Schlafzimmer : HM-SEC-SD | smokeDetector | 0042 | -
RM_Heizungskeller : HM-SEC-SD | smokeDetector | 0042 | -
RM_Kellerflur_Heizung : HM-SEC-SD-2 | smokeDetector | 00AA | -
RM_OG.Jami : HM-SEC-SD-2 | smokeDetector | 00AA | -
RM_OG.Kinder : HM-SEC-SD-2 | smokeDetector | 00AA | -
RM_Schlafzimmer : HM-SEC-SD-2 | smokeDetector | 00AA | -
RM_Vorratskeller : HM-SEC-SD-2 | smokeDetector | 00AA | -
RM_Werkzeugkeller : HM-SEC-SD-2 | smokeDetector | 00AA | -
Rauchmelder : virtual_1 | - | - | -
Rauchmelder_2 : virtual_1 | - | - | -
SW.motion.Aussen : HM-LC-SW2-FM | switch | 0009 | -
...
vccu : CCU-FHEM | virtual | FFF0 | -
Vielleicht hat es ja etwas zu bedeuten, dass die Rauchmelderteams keine mId haben?
Was muss ich tun (möglichst außer ,,restore"), um wieder ein fehlerfreies System zu haben?
LG
Holger
Zitat von: curt am 15 Januar 2019, 03:16:36
Wir sind mit diesem Beitrag schwer offtopic. Bitte ggf. auslagern!
[...]
Hab bitte lieber eine Idee, wie ich den Verursacher der Löscherei ausfindig mache. Das kann so ja nicht bleiben.
Fang' doch selber einen entsprechenden Beitrag an, kannst ja hier verlinken. Als Verdächtigen würde ich mal das alexa-Modul ansehen. Schau mal bei den Wetter-Diskussionen nach, da gab es auch erst den Verdacht, dass eine der neuen API's schuld gewesen wäre, dass plötzlich ohne erkennbaren Grund Zeilen in der cfg hops gegangen sind... Vielleicht ist es ja bei dir ähnlich?
Zitat von: curt am 15 Januar 2019, 03:16:36
Die habe ich aus dem Wiki abgeschrieben und in fhem.cfg reingeworden, vor über einem Jahr. (Jaja, sag nix. Nie fhem.cfg anfassen.)
Weiter OT: Auch wenn manche gerne files händisch editieren, man kann das auch ganz gut über den RAW-Import (https://wiki.fhem.de/wiki/Import_von_Code_Snippets) machen, und die Kombination von Ein- und Ausschalten kann man u.a. auch in einem Weekdaytimer realisieren.
Es wird noch etwas mysteriöser...
Gehe ich auf die Detailseite von HMinfo und löse dort über den Button ein
get hm configCheck aus, bekomme ich die Fehlermeldung wie etwas weiter oben beschrieben.
Führe ich
get hm configCheck in der FHEM-Kommandozeile aus, bekomme ich in Summe 2 Meldungen, die sich aber überlagern.
Zuunterst liegt ein Fenster mit "OK", darüber schiebt sich aber sehr schnell ein weiteres Fenster mit der oben beschriebenen Fehlermeldung.
Wenn ich das so lese, gilt für mich immer noch "Finger weg von einem Update".
Hallo,
erstmal Danke für das neue update.
Habe jedoch nach update von HMConfig.pm 18185 auf HMConfig.pm 18237 folgende Meldung im logfile:
PERL WARNING: Useless use of a variable in void context at FHEM/HMConfig.pm line 339, <$fh> line 603
Es funktioniert aber alles so wie es soll, soweit ich das nach einem kurzen check feststellen konnte.
Gruß Holger
dito
Die meldung werde ich entfernen. Ist absolut gefahrlos. Eben ein statement ohne auswirkung. Hat leider mein perl nicht gemeldet
@holger: die rauchmelder hatten keine mid, werden aber noch eine bekommen.
Unklar ist, warum deine devices keine .mId haben. Die gab es nicht, sollte jetzt aber angelegt werden. Zusammen mit der fehlermeldun .mId unknown komme ich unweigerlich zum Schluss dass du nicht die gepostete version von culhm nutzt.
Wenn du einen update machst ist das auch logisch. Zwischendurch hattest du einmal die neue version, sieht man am .mId
So weit scheint alles grün. Die Nutzer der geposteten version sollten die .mId sehen, das neue Schlüsselelement.
Danke für deine Rückmeldung.
Meine 10_CUL_HM ist Version 18184 vom 08.01.2019 - so weit ich das überblicke ist das doch die aktuelle Version. Ein "update check" zeigt mir auch keine ausstehenden Änderungen an.
Wenn ich noch alles richtig im Hinterkopf habe, hatte ich vor dem heutigen Update bei .mId bei - fast -allen Devices einen Wert stehen. Nach dem Update ist bei allen Devices das Feld leer.
Wie kann man denn jetzt die .mId neu generieren (ohne jetzt jedes Device einzeln anfassen zu müssen)?
Ich bin auch auf der Version 18184 und bei keinem meiner Devices sehe ich die .mId. Ich meine aber die war zwischenzeitlich mal enthalten. Ich sehe nicht mal das Feld. Unknown attribut Meldungen habe ich keine im Log.
Zitat von: Burny4600 am 09 Januar 2019, 19:48:10
Ich habe bei allen HM Geräten unbekannte Attribute. Fenstersensoren, Rauchmelder, Thermostate und Regler, Feuchtesensor usw.
configfile: VCCU: unknown attribute .mId. Type 'attr VCCU ?' for a detailed list.\
UEST1_AB_GAO: unknown attribute .mId. Type 'attr UEST1_AB_GAO ?' for a detailed list.\
UEST2_AB_GAO: unknown attribute .mId. Type 'attr UEST2_AB_GAO ?' for a detailed list.\
UESF1_AB_FR: unknown attribute .mId. Type 'attr UESF1_AB_FR ?' for a detailed list.\
UEST1_AB_FR: unknown attribute .mId. Type 'attr UEST1_AB_FR ?' for a detailed list.\
UEST1_AB_SA: unknown attribute .mId. Type 'attr UEST1_AB_SA ?' for a detailed list.\
UEST1_AB_GTW: unknown attribute .mId. Type 'attr UEST1_AB_GTW ?' for a detailed list.\
UESF1_AB_GAO: unknown attribute .mId. Type 'attr UESF1_AB_GAO ?' for a detailed list.\
UESF2_AB_GAO: unknown attribute .mId. Type 'attr UESF2_AB_GAO ?' for a detailed list.\
UESF1_EG_SL: unknown attribute .mId. Type 'attr UESF1_EG_SL ?' for a detailed list.\
UESF2_EG_SL: unknown attribute .mId. Type 'attr UESF2_EG_SL ?' for a detailed list.\
UESF1_EG_BA: unknown attribute .mId. Type 'attr UESF1_EG_BA ?' for a detailed list.\
UESF1_EG_WZ: unknown attribute .mId. Type 'attr UESF1_EG_WZ ?' for a detailed list.\
UESF2_EG_WZ: unknown attribute .mId. Type 'attr UESF2_EG_WZ ?' for a detailed list.\
UESF1_EG_KUE: unknown attribute .mId. Type 'attr UESF1_EG_KUE ?' for a detailed list.\
UEST1_EG_KUE: unknown attribute .mId. Type 'attr UEST1_EG_KUE ?' for a detailed list.\
UESF1_EG_WC: unknown attribute .mId. Type 'attr UESF1_EG_WC ?' for a detailed list.\
UESF1_EG_WI: unknown attribute .mId. Type 'attr UESF1_EG_WI ?' for a detailed list.\
UEST1_EG_STH: unknown attribute .mId. Type 'attr UEST1_EG_STH ?' for a detailed list.\
UESF1_EG_STH: unknown attribute .mId. Type 'attr UESF1_EG_STH ?' for a detailed list.\
UESF2_EG_STH: unknown attribute .mId. Type 'attr UESF2_EG_STH ?' for a detailed list.\
UESF3_OG1_STH: unknown attribute .mId. Type 'attr UESF3_OG1_STH ?' for a detailed list.\
UESF4_OG1_STH: unknown attribute .mId. Type 'attr UESF4_OG1_STH ?' for a detailed list.\
UESF5_OG2_STH: unknown attribute .mId. Type 'attr UESF5_OG2_STH ?' for a detailed list.\
UESF1_OG1_SL: unknown attribute .mId. Type 'attr UESF1_OG1_SL ?' for a detailed list.\
UESF2_OG1_SL: unknown attribute .mId. Type 'attr UESF2_OG1_SL ?' for a detailed list.\
UESF1_OG1_BA: unknown attribute .mId. Type 'attr UESF1_OG1_BA ?' for a detailed list.\
UESF1_OG1_WZ: unknown attribute .mId. Type 'attr UESF1_OG1_WZ ?' for a detailed list.\
UESF2_OG1_WZ: unknown attribute .mId. Type 'attr UESF2_OG1_WZ ?' for a detailed list.\
UESF1_OG1_KUE: unknown attribute .mId. Type 'attr UESF1_OG1_KUE ?' for a detailed list.\
UEST1_OG1_KUE: unknown attribute .mId. Type 'attr UEST1_OG1_KUE ?' for a detailed list.\
UESF1_OG1_WC: unknown attribute .mId. Type 'attr UESF1_OG1_WC ?' for a detailed list.\
UESF1_OG1_KI: unknown attribute .mId. Type 'attr UESF1_OG1_KI ?' for a detailed list.\
UESF1_OG2_BUE1_N: unknown attribute .mId. Type 'attr UESF1_OG2_BUE1_N ?' for a detailed list.\
UESF2_OG2_BUE1_N: unknown attribute .mId. Type 'attr UESF2_OG2_BUE1_N ?' for a detailed list.\
UESF3_OG2_BUE1_N: unknown attribute .mId. Type 'attr UESF3_OG2_BUE1_N ?' for a detailed list.\
UESF1_OG2_BUE2_N: unknown attribute .mId. Type 'attr UESF1_OG2_BUE2_N ?' for a detailed list.\
UESF2_OG2_BUE2_N: unknown attribute .mId. Type 'attr UESF2_OG2_BUE2_N ?' for a detailed list.\
UESF1_OG2_BUE2_W: unknown attribute .mId. Type 'attr UESF1_OG2_BUE2_W ?' for a detailed list.\
UESF2_OG2_BUE2_W: unknown attribute .mId. Type 'attr UESF2_OG2_BUE2_W ?' for a detailed list.\
UESF3_OG2_BUE2_W: unknown attribute .mId. Type 'attr UESF3_OG2_BUE2_W ?' for a detailed list.\
UESF1_OG2_DB: unknown attribute .mId. Type 'attr UESF1_OG2_DB ?' for a detailed list.\
UESF1_OG2_DBN: unknown attribute .mId. Type 'attr UESF1_OG2_DBN ?' for a detailed list.\
UESF2_OG2_DBN: unknown attribute .mId. Type 'attr UESF2_OG2_DBN ?' for a detailed list.\
UESF3_OG2_DBN: unknown attribute .mId. Type 'attr UESF3_OG2_DBN ?' for a detailed list.\
UEST1_OG2_EDV: unknown attribute .mId. Type 'attr UEST1_OG2_EDV ?' for a detailed list.\
KG_FS1_OA: unknown attribute .mId. Type 'attr KG_FS1_OA ?' for a detailed list.\
AB_GAO_FS1_SSPPWTI: unknown attribute .mId. Type 'attr AB_GAO_FS1_SSPPWTI ?' for a detailed list.\
OG1_KUE_FS1_OA: unknown attribute .mId. Type 'attr OG1_KUE_FS1_OA ?' for a detailed list.\
AB_GS_NM_RWS: unknown attribute .mId. Type 'attr AB_GS_NM_RWS ?' for a detailed list.\
AB_VG_BW: unknown attribute .mId. Type 'attr AB_VG_BW ?' for a detailed list.\
AB_SG_BW: unknown attribute .mId. Type 'attr AB_SG_BW ?' for a detailed list.\
OG2_B1_KG: unknown attribute .mId. Type 'attr OG2_B1_KG ?' for a detailed list.\
AB_FR_AAM: unknown attribute .mId. Type 'attr AB_FR_AAM ?' for a detailed list.\
EG_STH_AAM: unknown attribute .mId. Type 'attr EG_STH_AAM ?' for a detailed list.\
OG1_VR_AAM: unknown attribute .mId. Type 'attr OG1_VR_AAM ?' for a detailed list.\
OG2_BU1_AAM: unknown attribute .mId. Type 'attr OG2_BU1_AAM ?' for a detailed list.\
EG_BA_HZG_RT: unknown attribute .mId. Type 'attr EG_BA_HZG_RT ?' for a detailed list.\
EG_BA_HZG_TC: unknown attribute .mId. Type 'attr EG_BA_HZG_TC ?' for a detailed list.\
EG_KU_HZG_RT: unknown attribute .mId. Type 'attr EG_KU_HZG_RT ?' for a detailed list.\
EG_KU_HZG_TC: unknown attribute .mId. Type 'attr EG_KU_HZG_TC ?' for a detailed list.\
EG_SL_HZG_RT: unknown attribute .mId. Type 'attr EG_SL_HZG_RT ?' for a detailed list.\
EG_SL_HZG_TC: unknown attribute .mId. Type 'attr EG_SL_HZG_TC ?' for a detailed list.\
EG_STH_HZG_RT: unknown attribute .mId. Type 'attr EG_STH_HZG_RT ?' for a detailed list.\
EG_WC_HZG_RT: unknown attribute .mId. Type 'attr EG_WC_HZG_RT ?' for a detailed list.\
EG_WI_HZG_RT: unknown attribute .mId. Type 'attr EG_WI_HZG_RT ?' for a detailed list.\
EG_WZ_HZG_RT: unknown attribute .mId. Type 'attr EG_WZ_HZG_RT ?' for a detailed list.\
EG_WZ_HZG_TC: unknown attribute .mId. Type 'attr EG_WZ_HZG_TC ?' for a detailed list.\
OG1_KI_HZG_RT: unknown attribute .mId. Type 'attr OG1_KI_HZG_RT ?' for a detailed list.\
OG1_KI_HZG_TC: unknown attribute .mId. Type 'attr OG1_KI_HZG_TC ?' for a detailed list.\
OG1_KU_HZG_RT: unknown attribute .mId. Type 'attr OG1_KU_HZG_RT ?' for a detailed list.\
OG1_KU_HZG_TC: unknown attribute .mId. Type 'attr OG1_KU_HZG_TC ?' for a detailed list.\
OG1_SL_HZG_RT: unknown attribute .mId. Type 'attr OG1_SL_HZG_RT ?' for a detailed list.\
OG1_SL_HZG_TC: unknown attribute .mId. Type 'attr OG1_SL_HZG_TC ?' for a detailed list.\
OG1_STH_HZG_RT: unknown attribute .mId. Type 'attr OG1_STH_HZG_RT ?' for a detailed list.\
OG1_STH_HZG_TC_Weather_vt: unknown attribute .mId. Type 'attr OG1_STH_HZG_TC_Weather_vt ?' for a detailed list.\
OG1_WC_HZG_RT: unknown attribute .mId. Type 'attr OG1_WC_HZG_RT ?' for a detailed list.\
OG1_WC_HZG_TC_Weather_vt: unknown attribute .mId. Type 'attr OG1_WC_HZG_TC_Weather_vt ?' for a detailed list.\
OG1_WZ_HZG_RT: unknown attribute .mId. Type 'attr OG1_WZ_HZG_RT ?' for a detailed list.\
OG1_WZ_HZG_TC: unknown attribute .mId. Type 'attr OG1_WZ_HZG_TC ?' for a detailed list.\
OG2_BU1_HZG_RT: unknown attribute .mId. Type 'attr OG2_BU1_HZG_RT ?' for a detailed list.\
OG2_BU1_HZG_TC: unknown attribute .mId. Type 'attr OG2_BU1_HZG_TC ?' for a detailed list.\
OG2_BU2_HZG_RT1: unknown attribute .mId. Type 'attr OG2_BU2_HZG_RT1 ?' for a detailed list.\
OG2_BU2_HZG_RT2: unknown attribute .mId. Type 'attr OG2_BU2_HZG_RT2 ?' for a detailed list.\
OG2_BU2_HZG_TC: unknown attribute .mId. Type 'attr OG2_BU2_HZG_TC ?' for a detailed list.\
OG2_WC_HZG_RT: unknown attribute .mId. Type 'attr OG2_WC_HZG_RT ?' for a detailed list.\
EG_STH_T1_VR: unknown attribute .mId. Type 'attr EG_STH_T1_VR ?' for a detailed list.\
AB_SA_NT: unknown attribute .mId. Type 'attr AB_SA_NT ?' for a detailed list.\
EG_STH_T1_VG: unknown attribute .mId. Type 'attr EG_STH_T1_VG ?' for a detailed list.\
EG_STH_T1_FB: unknown attribute .mId. Type 'attr EG_STH_T1_FB ?' for a detailed list.\
AB_FR_RM: unknown attribute .mId. Type 'attr AB_FR_RM ?' for a detailed list.\
RM_TeamDev_ABFR: unknown attribute .mId. Type 'attr RM_TeamDev_ABFR ?' for a detailed list.\
AB_GAO_RM: unknown attribute .mId. Type 'attr AB_GAO_RM ?' for a detailed list.\
RM_TeamDev_ABGAO: unknown attribute .mId. Type 'attr RM_TeamDev_ABGAO ?' for a detailed list.\
RM_TeamDev_EG: unknown attribute .mId. Type 'attr RM_TeamDev_EG ?' for a detailed list.\
OG1_KI_RM: unknown attribute .mId. Type 'attr OG1_KI_RM ?' for a detailed list.\
OG1_KUE_RM: unknown attribute .mId. Type 'attr OG1_KUE_RM ?' for a detailed list.\
OG1_SL_RM: unknown attribute .mId. Type 'attr OG1_SL_RM ?' for a detailed list.\
OG1_VR_RM: unknown attribute .mId. Type 'attr OG1_VR_RM ?' for a detailed list.\
OG1_WZ_RM: unknown attribute .mId. Type 'attr OG1_WZ_RM ?' for a detailed list.\
RM_TeamDev_OG1: unknown attribute .mId. Type 'attr RM_TeamDev_OG1 ?' for a detailed list.\
OG2_BU1_RM: unknown attribute .mId. Type 'attr OG2_BU1_RM ?' for a detailed list.\
OG2_BU2_RM: unknown attribute .mId. Type 'attr OG2_BU2_RM ?' for a detailed list.\
OG2_EDV_RM: unknown attribute .mId. Type 'attr OG2_EDV_RM ?' for a detailed list.\
OG2_DB_RM: unknown attribute .mId. Type 'attr OG2_DB_RM ?' for a detailed list.\
OG2_VR_RM: unknown attribute .mId. Type 'attr OG2_VR_RM ?' for a detailed list.\
RM_TeamDev_OG2: unknown attribute .mId. Type 'attr RM_TeamDev_OG2 ?' for a detailed list.\
AB_GAO_BWS: unknown attribute .mId. Type 'attr AB_GAO_BWS ?' for a detailed list.\
AB_FR_AD: unknown attribute .mId. Type 'attr AB_FR_AD ?' for a detailed list.\
Mittlerweile Backup wieder eingespielt.
Hallo,
bei mir liegt gleiches Problem vor.
In den HM Devices existiert das Attribut .mId.
Habe 10_CUL_HM.pm + 00_HMLAN.pm vom update ausgeschlossen.
Ich habe diesen thread schon 2 mal durchgelesen, blicke aber nicht durch ob ich was falsch mache oder nur warten muss bis ein vermeintlicher Fehler behoben wird.
Danke für Infos und VG
Dieter
Für die quereinsteiger: nach den Problemen gab es einen rolback. Die Version im Update ist demnach alt.
Die neue Version ist etwas weiter hier gepostet und kann manuell eingespielt werden. Dann gibt's auch eine. mId.
Tests mit der alten Version sind nicht erforderlich. Die ist seit längerem stabil.
Ok, jetzt hab ich es verstanden. Ein Update ist also zur Zeit bezüglich der hier geschilderten Probleme mit HM gefahrlos.
Hi,
ich habe grade das Update durchgeführt,
auf den ersten Blick scheint alles normal zu funktionieren, hab im Log aber diese meldung:
2019.01.16 20:06:19.876 1: PERL WARNING: Useless use of a variable in void context at FHEM/HMConfig.pm line 339, <$fh> line 109.
2019.01.16 20:06:19.877 1: stacktrace:
2019.01.16 20:06:19.877 1: main::__ANON__ called by FHEM/HMConfig.pm (339)
2019.01.16 20:06:19.877 1: (eval) called by ./FHEM/10_CUL_HM.pm (10)
2019.01.16 20:06:19.878 1: main::BEGIN called by FHEM/HMConfig.pm (2314)
2019.01.16 20:06:19.878 1: (eval) called by FHEM/HMConfig.pm (2314)
2019.01.16 20:06:19.878 1: (eval) called by fhem.pl (2556)
2019.01.16 20:06:19.878 1: (eval) called by fhem.pl (2555)
2019.01.16 20:06:19.878 1: main::CommandReload called by fhem.pl (1954)
2019.01.16 20:06:19.879 1: main::LoadModule called by fhem.pl (2011)
2019.01.16 20:06:19.879 1: main::CommandDefine called by fhem.pl (1224)
2019.01.16 20:06:19.879 1: main::AnalyzeCommand called by fhem.pl (1070)
2019.01.16 20:06:19.880 1: main::AnalyzeCommandChain called by fhem.pl (1365)
2019.01.16 20:06:19.880 1: main::CommandInclude called by fhem.pl (587)
Zitat von: martinp876 am 16 Januar 2019, 19:45:37
Für die quereinsteiger: nach den Problemen gab es einen rolback. Die Version im Update ist demnach alt.
Die neue Version ist etwas weiter hier gepostet und kann manuell eingespielt werden. Dann gibt's auch eine. mId.
Tests mit der alten Version sind nicht erforderlich. Die ist seit längerem stabil.
Ok, danke für die Antwort. Hat schon mal funktioniert.
Nach einem Update Check wird mir die 10_CUL_HM.pm angeboten.
Kann man die jetzt ohne Fehler updaten oder besser ausschließen?
Also noch einmal:
- die version in svn ist seit etwa 1 woche wieder auf dem alten stand und somit erprobt
- hmconfig ist neu und gefahrlos. Die unschöne aber absolut ungefährliche Warnung ist seit gestern beseitigt.
- eigentlich habe ich hier den code gepostet, welchen ich am wochenende einspielen werde, damit er von euch getestet werden kann. Ich warte noch auf feedback.
Hallo Martin,
nach einem kurzen Test auf meinem Testsystem der oben angehangenen 10_CUL_HM.pm und aktueller HMConfig.pm funktioniert alles einwandfrei.
Habe einige HM-Funktionstests durchgeführt, save und 2x FHEM neu gestartet. Keine Auffälligkeiten.
Hier noch der Output von
fhem> get hm param -d model subType mId .mId
param done:
param list
entity : model | subType | mId | .mId |
HM_56864A : HM-CC-RT-DN | thermostat | 0095 | 0095
HM_588EDE : HM-PB-2-WM55-2 | pushButton | 00C2 | 00C2
KFM100 : KFM-Sensor | KFM100 | 0047 | 0047
TeamDev : VIRTUAL | virtual | FFF1 | -
az_Thermostat : HM-CC-RT-DN | thermostat | 0095 | 0095
door_SC : HM-SEC-SCo | threeStateSensor | 00C7 | 00C7
ke_Switch4 : HM-LC-SW4-WM | switch | 0066 | 0066
sd_Test : HM-SEC-SD | smokeDetector | 0042 | 0042
sz_Lichtschalter : HM-PB-2-WM55-2 | pushButton | 00C2 | 00C2
sz_Rollo : HM-LC-Bl1PBU-FM | blindActuator | 0005 | 006A
te_Sensor : HB-UW-Sen-THPL-O | THPLSensor | F102 | F102
test_Lichtschalter : HM-RC-2-PBU-FM | remote | 00E0 | 00E0
vccu : CCU-FHEM | virtual | FFF0 | -
wz_Tuer_SC : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
Gruß
Tobias
hab gestern auch das update durchgeführt und keine weiteren auffälligkeiten, aber .mId hab ich keine Werte drin!?
param done:
param list
entity : model | subType | mId | .mId |
Bewegungsmelder : HM-SEC-MDIR-2 | motionDetector | 00C0 | -
Fenster_Laya : HM-SEC-SCo | threeStateSensor | 00C7 | -
Fenster_neben_Couch : HM-SEC-RHS | threeStateSensor | 0030 | -
Fenster_ueber_Heizung : HM-SEC-RHS | threeStateSensor | 0030 | -
Flur_EG : HM-SEC-SD | smokeDetector | 0042 | -
Funkschalter_Keller_Licht : HM-LC-SW1-FM | switch | 0004 | -
Gaeste_WC : HM-CC-RT-DN | thermostat | 0095 | -
Gaeste_WC_Fenster : HM-SEC-SCo | threeStateSensor | 00C7 | -
HeizungFenster : HM-CC-RT-DN | thermostat | 0095 | -
Heizung_Flur : HM-CC-RT-DN | thermostat | 0095 | -
Heizung_Kinderzimmer : HM-CC-RT-DN | thermostat | 0095 | -
Heizung_Tuer : HM-CC-RT-DN | thermostat | 0095 | -
Keller : HM-SEC-SD | smokeDetector | 0042 | -
Kinderzimmer_Laya : HM-CC-RT-DN | thermostat | 0095 | -
Kinderzimmer_Mila : HM-SEC-SD | smokeDetector | 0042 | -
Kueche : HM-CC-RT-DN | thermostat | 0095 | -
Mila_Fenster : HM-SEC-SCo | threeStateSensor | 00C7 | -
Rauchmelder : virtual_1 | virtual | - | -
Rauchmelder_Kinderzimmer_Laya : HM-SEC-SD | smokeDetector | 0042 | -
Terassen_Tuer : HM-SEC-RHS | threeStateSensor | 0030 | -
vccu : CCU-FHEM | virtual | FFF0 | -
Hmm, das sieht mit # $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $ von der vorletzten Seite bei mir aber anders aus. FHEM ansonsten aktuell.
param done:
param list
entity : model | subType | mId | .mId |
Arbeits_rechts : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
Bad_Dachfenster : HM-SEC-SCo | threeStateSensor | 00C7 | 00C7
Bad_unten : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
Gaeste_Fenster_Strasse : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
HM_5A5754 : HASH(0x48b14f8) | - | - | -
HM_5A6710 : HASH(0x48b14f8) | - | - | -
HM_5A6737 : HASH(0x48b14f8) | - | - | -
Haustuer : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
Heizungsraum : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
Jonny_Fenster_rechts : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
Kueche : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
Schlaf_links : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
TeamDev : virtual_1 | virtual | FFF1 | -
Terrassentuer : HM-SEC-SC-2 | threeStateSensor | 002F | 00B1
VCCU : CCU-FHEM | virtual | FFF0 | -
Die Hash-Kumpels sind Rauchmelder.
@Thommy82: du hast die SVN version. Interessiert nicht :(
@curt: Sieht gut aus. Bis auf die HM_xxxxx teile. Wo kommen diese her? Sind die automatisch angelegt worden - über die VCCU und IgnoreDevice?
Zitat von: martinp876 am 19 Januar 2019, 08:02:44
@curt: Sieht gut aus. Bis auf die HM_xxxxx teile. Wo kommen diese her? Sind die automatisch angelegt worden - über die VCCU und IgnoreDevice?
Homematic-Rauchmelder, von hier: https://www.amazon.de/gp/product/B002WS2NPS/ - also HM-Sec-SD-2. Angelegt hatte ich sie nach Anleitung, pairen und peeren und rumärgern.
Die drei sind in diesem Rauchmelder_Team und melden sich auch artig bei der VCCU.
Hallo,
ich habe heute ein Update gemacht. Jetzt auch diese Fehlermeldung:
Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet templateDel
So, wie ich es hier verstanden habe, sollte doch die aktuell eingecheckte Version funktionieren?
Hallo Gemeinde,
ich möchte mich an dieser Stelle einmal auch zu Wort melden. Auch ich hatte große Bedenken ein Update zu machen.
Jedoch habe ich aufgrund der Aussage von Martinp ein Update gemacht und alles ist - wie beschrieben von Martin -
danach in Ordnung. Es gibt KEINE Variable .mId nach dem Update bei mir, und auch keine sonstigen Fehler.
Will sagen, dass die momentane Version im Update in Ordnung ist. Falls Fehler auftreten, muss es woanders dran
liegen, oder es sind noch Reste eines vorigen Updates bei demjenigen enthalten, wo es noch nicht funktioniert hat.
VG
mcfly
Zitat von: mcfly71 am 22 Januar 2019, 07:24:53
Hallo Gemeinde,
ich möchte mich an dieser Stelle einmal auch zu Wort melden. Auch ich hatte große Bedenken ein Update zu machen.
Jedoch habe ich aufgrund der Aussage von Martinp ein Update gemacht und alles ist - wie beschrieben von Martin -
danach in Ordnung. Es gibt KEINE Variable .mId nach dem Update bei mir, und auch keine sonstigen Fehler.
Will sagen, dass die momentane Version im Update in Ordnung ist. Falls Fehler auftreten, muss es woanders dran
liegen, oder es sind noch Reste eines vorigen Updates bei demjenigen enthalten, wo es noch nicht funktioniert hat.
VG
mcfly
Guten Morgen zusammen,
ich kann dies nur bestätigen. Gerade ein Update durchgeführt und alles läuft danach.
Danke für die Arbeit!
Grüße
Fabian
Hallo zusammen,
bei mir funktioniert auch wieder alles. Ich habe den Threat überfolgen und möchte nochmal deutlich meinen Dank an alle Entwickler aussprechen die hier Module usw. bauen. Ihr macht das ja alles in eurer Freizeit.
Ich bekomme nach dem Fhem Start nur noch diese "mID" Fehler. (siehe Bild). Gab es dafür eine Erklärung/Abhilfe?
Zitat von: Borkk am 22 Januar 2019, 10:08:26
Ich bekomme nach dem Fhem Start nur noch diese "mID" Fehler. (siehe Bild). Gab es dafür eine Erklärung/Abhilfe?
Ja. In diesem Thread.
Zitat von: marvin78 am 22 Januar 2019, 11:40:03
Ja. In diesem Thread.
Ein ausnehmend "hilfreicher" Beitrag. Das muss ich schon sagen.
Übrigens hängen bei mir mit der Testversion -wie oben beschrieben- drei Devices.
ZitatJa. In diesem Thread.
Ich dachte eigentlich, ich hatte nett gefragt. Vielleicht bekomme ich eine Zahl als Antwort :)
1.) Muss ich das Modul händisch ersetzen?
2.) Da ja alles läuft warte ich bis es ein "richtiges" Update gibt.
3.) Ich muss alle 10 Seiten dieses Threads Wort für Wort lesen um das "Ja. In diesem Thread." zu finden.
Danke für eine Antwort.
(PS: Bitte nicht zu ernst nehmen ;))
Zitat von: Borkk am 22 Januar 2019, 21:30:09
3.) Ich muss alle 10 Seiten dieses Threads Wort für Wort lesen um das "Ja. In diesem Thread." zu finden.
Danke für eine Antwort.
Im geöffneten Thread oben in der Suchmaske einen Teil der Meldung eingeben:
unknown .mIdUnd der dritte Treffer passt ;D ::) ;D
Gruß Otto
Wie man an Ottos Beitrag sieht, kann dich meine Antwort schnell zum Ergebnis führen. Wenn du nur willst... Aber es war sicher weniger Aufwand, den Beschwerde Beitrag zu schrieben ::)
OT:
Zitat von: marvin78 am 22 Januar 2019, 21:43:36
Wie man an Ottos Beitrag sieht, kann dich meine Antwort schnell zum Ergebnis führen.
Mag sein. Es bleibt trotzdem eine Nichtantwort, die im usenet im Namensraum *linux verbreitet war. Ich finde das nervig. Denn bei solchen Threads geht es bunt durcheinander: Binnen weniger Tage wurden drei verschiedene Versionen diskutiert. Da fällt schon schwer zu erkennen, was hier eigentlich noch aktuell und was veraltet ist.
Wäre es denn schlimm gewesen, wenn Du "Lies Beitrag #xy dieses Threads" geschrieben hättest?
Wenn ich nun schon mal dabei bin - eins stört mich auch noch: Es gehört hier im Forum zum Ton, immer erstmal einen Kniefall vor den Entwicklern zu machen. Ja sicher: Es ist sehr schön, dass das viele Freiwllige machen. Und dafür sind wir Nutzer auch alle dankbar. Andererseits ist es schon so, dass das Projekt eine Größe hat, die auch Erwartungshaltungen erzeugt: Wir reden doch nicht über ein Computerspiel. Wir reden über was, was viele in existenziellen Bereichen ihres Lebens einsetzen. Da kann man schon eine gewisse Beständigkeit erwarten.
Mit Verlaub.
P.S. Drei meiner Devices werden mit der neuen Testversion nur als Hash erkannt. Ich erwähnte es schon. Für Dich speziell nochmal erwähnt.
Unverhofft kommt oft.
Ich hatte die vom Modulautoren testweise in diesem Thread angebotene Testversion. Bis auf die drei Rauchmelder (die kommen als Hash) sah alles gut aus.
Und dann fuhr ich soeben ein Update. Das hätte ich lieber sein lassen sollen: Der komplette (!) unknown-Zirkus ist wieder da. Und läßt sich auch nicht mehr mit shutdown restart beheben.
Gna.
Zitat von: curt am 23 Januar 2019, 00:11:18
.
P.S. Drei meiner Devices werden mit der neuen Testversion nur als Hash erkannt. Ich erwähnte es schon. Für Dich speziell nochmal erwähnt.
Das ist ein anderes Thema. Du wirfst die Dinge durcheinander. Wie so viele User hier. Die neue Testversion, mit der ich nichts zu tun habe, sollte aus meiner Sicht in einem neuen Threads diskutiert werden. Zudem gehst du die Sache falsch an, wenn du wirklich Hilfe bei dem Thema haben möchtest. Eine Antwort, die auf den Ort der Lösung zeigt ist sicher hilfreicher, als eine Angaben zu deinem Problem für den Entwickler.
Deine Argumentation ist leider falsch herum. Warum, habe ich schon oft erklärt. Ich bin hier raus. Das Thema sollte ohnehin schon lang erledigt sein. Für weiteres würde ich in anderen Themen weiter machen, aber das ist Martins Sache.
Hallo zusammen,
ich wollte heute endlich mal wieder einige Dinge in FHEM ergänzen.
Bevor ich so was mache, spiele ich, wie heute als erstes den neusten FHEM-Stand ein.
Leider erscheint jetzt
unknown attribute .mId.
bei jedem Device.
Messages collected while initializing FHEM:
configfile: ActionDetector: unknown attribute .mId. Type 'attr ActionDetector ?' for a detailed list.
Zentrale_VCCU: unknown attribute .mId. Type 'attr Zentrale_VCCU ?' for a detailed list.
Zentrale_vTeamLead: unknown attribute .mId. Type 'attr Zentrale_vTeamLead ?' for a detailed list.
ThermostatHM__DG_Eingang: unknown attribute .mId. Type 'attr ThermostatHM__DG_Eingang ?' for a detailed list.
ThermostatHM__DG_Wald: unknown attribute .mId. Type 'attr ThermostatHM__DG_Wald ?' for a detailed list.
SteckdoseHM_Drucker__DG_Wald: unknown attribute .mId. Type 'attr SteckdoseHM_Drucker__DG_Wald ?' for a detailed list.
AktorHM__OG_Treppenhaus: unknown attribute .mId. Type 'attr AktorHM__OG_Treppenhaus ?' for a detailed list.
TasterHM__DG_Treppe_4x: unknown attribute .mId. Type 'attr TasterHM__DG_Treppe_4x ?' for a detailed list.
ThermostatHM__OG_Eingang: unknown attribute .mId. Type 'attr ThermostatHM__OG_Eingang ?' for a detailed list.
ThermostatHM__OG_Wald: unknown attribute .mId. Type 'attr ThermostatHM__OG_Wald ?' for a detailed list.
ThermostatHM__OG_Bad: unknown attribute .mId. Type 'attr ThermostatHM__OG_Bad ?' for a detailed list.
Licht__EG_Eingang: unknown attribute .mId. Type 'attr Licht__EG_Eingang ?' for a detailed list.
AktorHM__EG_Eingang: unknown attribute .mId. Type 'attr AktorHM__EG_Eingang ?' for a detailed list.
DimHM__LED__EG_Treppe: unknown attribute .mId. Type 'attr DimHM__LED__EG_Treppe ?' for a detailed list.
SteckdoseHM_Sissi__EG_Eingang: unknown attribute .mId. Type 'attr SteckdoseHM_Sissi__EG_Eingang ?' for a detailed list.
TasterHM__EG_Wohnzimmer_4x: unknown attribute .mId. Type 'attr TasterHM__EG_Wohnzimmer_4x ?' for a detailed list.
TasterHM__EG_Kueche_4x: unknown attribute .mId. Type 'attr TasterHM__EG_Kueche_4x ?' for a detailed list.
TasterHM__EG_Treppe_4x: unknown attribute .mId. Type 'attr TasterHM__EG_Treppe_4x ?' for a detailed list.
TasterHM__EG_Treppe_6x: unknown attribute .mId. Type 'attr TasterHM__EG_Treppe_6x ?' for a detailed list.
ThermostatHM__EG_Wald: unknown attribute .mId. Type 'attr ThermostatHM__EG_Wald ?' for a detailed list.
WandthermostatHM__EG_Treppe: unknown attribute .mId. Type 'attr WandthermostatHM__EG_Treppe ?' for a detailed list.
SteckdoseHM_IPCam__EG_Kueche: unknown attribute .mId. Type 'attr SteckdoseHM_IPCam__EG_Kueche ?' for a detailed list.
SteckdoseHM_HDMI_2_RJ45__EG_Wohnzimmer: unknown attribute .mId. Type 'attr SteckdoseHM_HDMI_2_RJ45__EG_Wohnzimmer ?' for a detailed list.
SteckdoseHM_Media__EG_Wohnzimmer: unknown attribute .mId. Type 'attr SteckdoseHM_Media__EG_Wohnzimmer ?' for a detailed list.
ActorHM_LuefterMultimedia__EG_Wohnzimmer: unknown attribute .mId. Type 'attr ActorHM_LuefterMultimedia__EG_Wohnzimmer ?' for a detailed list.
OTH_AussenfuehlerHM__EG_Donna: unknown attribute .mId. Type 'attr OTH_AussenfuehlerHM__EG_Donna ?' for a detailed list.
RemoteHM_Kirstin: unknown attribute .mId. Type 'attr RemoteHM_Kirstin ?' for a detailed list.
RemoteHM_Uwe: unknown attribute .mId. Type 'attr RemoteHM_Uwe ?' for a detailed list.
RemoteHM_Donna: unknown attribute .mId. Type 'attr RemoteHM_Donna ?' for a detailed list.
RemoteHM_Sam: unknown attribute .mId. Type 'attr RemoteHM_Sam ?' for a detailed list.
SD_RauchmelderHM__EG_Kueche: unknown attribute .mId. Type 'attr SD_RauchmelderHM__EG_Kueche ?' for a detailed list.
WassersensorHM__EG_Kueche: unknown attribute .mId. Type 'attr WassersensorHM__EG_Kueche ?' for a detailed list.
SD_RauchmelderHM__OG_Flur: unknown attribute .mId. Type 'attr SD_RauchmelderHM__OG_Flur ?' for a detailed list.
WassersensorHM__OG_Bad: unknown attribute .mId. Type 'attr WassersensorHM__OG_Bad ?' for a detailed list.
SD_RauchmelderHM__DG_Flur: unknown attribute .mId. Type 'attr SD_RauchmelderHM__DG_Flur ?' for a detailed list.
WassersensorHM__DG_Waschraum: unknown attribute .mId. Type 'attr WassersensorHM__DG_Waschraum ?' for a detailed list.
FunkGongHM__DG_Eingang: unknown attribute .mId. Type 'attr FunkGongHM__DG_Eingang ?' for a detailed list.
IR_KontaktHM__EG_Eingang: unknown attribute .mId. Type 'attr IR_KontaktHM__EG_Eingang ?' for a detailed list.
IR_KontaktHM__EG_Kueche: unknown attribute .mId. Type 'attr IR_KontaktHM__EG_Kueche ?' for a detailed list.
IR_KontaktHM__EG_Wohnzimmer: unknown attribute .mId. Type 'attr IR_KontaktHM__EG_Wohnzimmer ?' for a detailed list.
IR_KontaktHM__EG_HV: unknown attribute .mId. Type 'attr IR_KontaktHM__EG_HV ?' for a detailed list.
PIR_MotionHM__EG_Wohnzimmer: unknown attribute .mId. Type 'attr PIR_MotionHM__EG_Wohnzimmer ?' for a detailed list.
PIR_MotionHM__EG_Kueche: unknown attribute .mId. Type 'attr PIR_MotionHM__EG_Kueche ?' for a detailed list.
PIR_MotionHM__EG_Eingang: unknown attribute .mId. Type 'attr PIR_MotionHM__EG_Eingang ?' for a detailed list.
IR_KontaktHM__OG_Wald_rechts: unknown attribute .mId. Type 'attr IR_KontaktHM__OG_Wald_rechts ?' for a detailed list.
IR_KontaktHM__OG_Wald_links: unknown attribute .mId. Type 'attr IR_KontaktHM__OG_Wald_links ?' for a detailed list.
IR_KontaktHM__OG_Eingang_rechts: unknown attribute .mId. Type 'attr IR_KontaktHM__OG_Eingang_rechts ?' for a detailed list.
IR_KontaktHM__OG_Eingang_links: unknown attribute .mId. Type 'attr IR_KontaktHM__OG_Eingang_links ?' for a detailed list.
Durch das Lesen dieses Thread bin ich nun leider auch nicht schlauer geworden.
Ich habe das so verstanden, dass die Messages nun weg sein sollten.
Was habe ich übersehen?
Was muss ich nun tun, um das zu beheben?
Immer noch das Backup einspielen?
Danke für eure Hilfe.
CU Leeloo
Einfach save drücken und neu starten.
Komisch, hatte ich eigentlich gemacht.
==> So einfach kann die Welt sein. ;D
DANKE !!!
==> NACHTRAG ========>
So einfach ist es wohl noch nicht ganz.
Ein ConfigCheck meldet noch:
configCheck done:
missing register list
Zentrale_vTeamLead: RegL_00.
PairedTo missing/unknown
Zentrale_vTeamLead
Zentrale_vTeamLead = Device, um HM-Rauchmelder einfacher zu verwalten
Gibts noch was bei den Rauchmelderm zu beachten?
Mach mal bitte ein list Zentrale_vTeamLead
Hier das Ergebnis von "List Zentrale_vTeamLead"
[codeInternals:
CFGFN /opt/fhem/mycfg/10_Zentrale_CCD.cfg
DEF 911911
FUUID 5c486142-f33f-b5a5-a25d-df66a229c8dcaecb
IODev Zentrale_CCD
LASTInputDev Zentrale_CCD
MSGCNT 18
NAME Zentrale_vTeamLead
NOTIFYDEV global
NR 386
NTFY_ORDER 50-Zentrale_vTeamLead
STATE CMDs_done
TYPE CUL_HM
Zentrale_CCD_MSGCNT 18
Zentrale_CCD_RAWMSG 05010120D41441911911F10815010401000006ACAE24E5
Zentrale_CCD_RSSI -32
Zentrale_CCD_TIME 2019-01-23 14:31:08
channel_01 Zentrale_vTeamLead_Btn1__Rauchmelder
lastMsg No:D4 - t:41 s:911911 d:F10815 010401000006ACAE24E5
protCmdDel 1
protLastRcv 2019-01-23 14:31:05
protRcv 3 last_at:2019-01-23 14:31:05
protRcvB 3 last_at:2019-01-23 14:31:05
protResnd 3 last_at:2019-01-23 14:27:18
protResndFail 1 last_at:2019-01-23 14:27:22
protSnd 19 last_at:2019-01-23 14:31:00
protSndB 18 last_at:2019-01-23 14:31:00
protState CMDs_done
rssi_at_Zentrale_CCD cnt:18 min:-35 max:-32 avg:-33.16 lst:-32
READINGS:
2018-03-30 07:32:03 battery ok
2019-01-23 14:31:00 state CMDs_done
RegL_00.:
VAL
helper:
HM_CMDNR 212
cSnd ,01F1081591191100040000000000
mId FFF1
regLst ,0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +911911,00,01,00
nextSend 1548250269.00463
prefIO
rxt 0
vccu
p:
911911
00
01
00
mRssi:
mNo D4
io:
Zentrale_CCD:
-24
-24
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rssi:
at_Zentrale_CCD:
avg -33.1666666666667
cnt 18
lst -32
max -32
min -35
tmpl:
Attributes:
IODev Zentrale_CCD
autoReadReg 4_reqStatus
expert 2_raw
group System,System_vDevices
icon secur_smoke_detector
model VIRTUAL
room SYSTEM
webCmd update
Hmm, bei mir sehen die Attribute anders aus.
model virtual_1
subType virtual
Hast Du die gesetzt?
Gruß Otto
Das Ding hab ich schon lange laufen und irgendwann mal so definiert:
define Zentrale_vTeamLead CUL_HM 911911
setuuid Zentrale_vTeamLead 5c486142-f33f-b5a5-a25d-df66a229c8dcaecb
attr Zentrale_vTeamLead IODev Zentrale_CCD
attr Zentrale_vTeamLead autoReadReg 4_reqStatus
attr Zentrale_vTeamLead expert 2_raw
attr Zentrale_vTeamLead group System,System_vDevices
attr Zentrale_vTeamLead icon secur_smoke_detector
attr Zentrale_vTeamLead model VIRTUAL
attr Zentrale_vTeamLead room SYSTEM
a) setuuid ist heute (beim Update) neu hinzugekommen
b) subType kannte ich bei der damaligen Definition nicht. Habe es bis dato wohl nicht gebraucht.
Weitere Ideen?
eigentlich legt er beim define beide Attribute selbst an.
Ob diese attribute existentiell oder egal für das TeamDev kann ich nicht sagen.
Alle virtuellen devices bekommen das attr subType virtual.
Zitat von: martinp876 am 23 Januar 2019, 21:24:29
Alle virtuellen devices bekommen das attr subType virtual.
ein paar tage anfang januar sah das nach update aber genauso aus.
also ggf fhem erst einmal updaten.
Moin,
zur besseren Einordnung.
Die Definition
define Zentrale_vTeamLead CUL_HM 911911
wurde schon vor über 12 Monaten gemacht.
Die oben benannte Definition wurde damals von FHEM so erstellt.
Erst nach dem gestrigen Update liefert ein ConfigCheck diesen Eintrag.
======= Nachtrag ===============>
Ich hab die Einträge jetzt manuell nachgetragen/geändert.
Der "ConfigCheck" is jetzt wieder leer.
Ich hoffe, dass der Rest jetzt auch noch funktioniert.
Der Eintrag ist korrekt aber mir Sicherheit unvollständig. Der teamlead ist ein Kanal. Bislang hast du ein Device. Nun noch ein set ... virtual 1 und du hast den Kanal sowie das Attribut.
Das hatte subtype sollte automatisch gesetzt werden. Nach dem Update in Vorbereitung wird es auch verriegelt sein.
Allerdings brauche ich noch etwas Zeit für ein vereinfachtes peeren.
Sorry, hab es nicht vollständig beschrieben.
Ich habe früher bereits beides "Device" und "Kanal" definiert. Die Daten zum Kanal hatte ich hier nicht aufgeführt.
Seit meinen manuellen Nachtrag bzw. der Änderung von "VIRTUAL" in "virtual_1" und der Ergänzung von "subtype virtual" läuft alles stabil.
Gleichzeitig liefert ein ConfigCheck keinen Hinweis.
Lass Dir keinen Streß mit dem Update machen. Eventuelle Nacharbeiten anderer sollten jetzt zumindest ebenfalls zur Lösung führen/finden.
Wenn man mit dem jetzigen Stand einen teamlead samt Kanal anlegt gibt es folgendes Ergebnis:
define TEST_vTeamLead CUL_HM 911911
setuuid TEST_vTeamLead 5c4ed3c8-f33f-b5a5-6a7e-740e74508910b950
attr TEST_vTeamLead expert 2_raw
attr TEST_vTeamLead model virtual_1
attr TEST_vTeamLead subType virtual
attr TEST_vTeamLead webCmd virtual
define TEST_vTeamLead_Btn1 CUL_HM 91191101
setuuid TEST_vTeamLead_Btn1 5c4ed3ce-f33f-b5a5-cadd-ff81d28d45bfc7b2
attr TEST_vTeamLead_Btn1 model virtual_1
attr TEST_vTeamLead_Btn1 peerIDs
attr TEST_vTeamLead_Btn1 webCmd press short:press long
Dir eine schöne Woche und nochmals ein großes Danke für deine Arbeit in FHEM sowie dem Forum.
Zitat von: CoolTux am 23 Januar 2019, 14:13:27
Einfach save drücken und neu starten.
Hallo,
das habe ich nun auch mal gewagt und siehe da, alles gut.
Nur komme ich mit diesen Infos nicht weiter:
configCheck done:
missing register list
TeamDev: RegL_00.
PairedTo missing/unknown
TeamDev
templist mismatch
Thermostat_Bad_Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directoryBeispiel Fenster_Erker
Set getConfig und neu Anlernen ohne Erfolg.Mittlerweile behoben.
Wie muss ich vorgehen?
Danke für Hilfe und VG
Dieter
wahrscheinlich attribute korrigieren.
Zitat von: frank am 07 Februar 2019, 17:36:40
wahrscheinlich attribute korrigieren.
Sehr gut, jetzt configCheck done: "leer"
Vielen Dank und schönen Abend noch.
Neuer Pi, neues Glück ;D
10_CUL_HM.pm aus dem exclude_from_update (wo es seit Anfang Januar nach den ersten Versuchen mit mId stand ->
# $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $
# $Id: HMConfig.pm 18284 2019-01-16 18:56:58Z martinp876 $
shutdown und restart.
Und nun, wider Erwarten, weit und breit nichts von mId oder .mId in der fhem.cfg.
# $Id: 10_CUL_HM.pm 18113 2019-01-01 16:53:31Z martinp876 $
ist identisch zur obigen.
Sind die mId jetzt doch noch nicht scharf? hier reden doch alle die ganze Zeit davon ...
Noch nicht. Es gab kein Update.
so, vor dem update noch einmal ein aufruf zum Testen.
Leider habe ich peerSmart noch nicht einsatzbereit....
HMConfig sollte bei euch schon auf dem aktuellen Stand sein (seit Wochen in SVN)
Es gibt interne Umstellungen aber auch bug behebungen beim Register lesen
:) :) :) nach erstem Eindruck - geht alles, auch die virtuellen Türkontakte, Rauchmelder Teamdevice. Danke und Daumen hoch!
:-\ eine Stunde später nach inzwischen 2 Totalabstürzen - da ist wohl doch noch was. Sorry, verbose ist bei mir nur auf 2, daher kann ich nur mit folgendem aus dem LOG dienen:
Can't use string ("33") as an ARRAY ref while "strict refs" in use at ./FHEM/10_CUL_HM.pm line 10000.
wäre auch mutig, bin aber leider die nächsten vier Tage von meinem FHEM getrennt ... sorry...
Keine Tester? Bei mir läuft es nun schon ein paar Wochen. Keine Probleme.
Mit der FehlerMeldung kann ich wenig anfangen.
Mein Pi hatte einen Aussetzer und musste gebootet werden. Datenbank Problem. Nicht alles ist culhm..
Moinsen,
danke für die Erinnerung. Wollte auch noch testen. Reicht es das Modul aus Beitrag 168 zu installieren oder gibt es schon was aktuelleres?
Dann werde ich das heute nochmal installieren.
Viele Grüße Hoppel
Hab's eben auch getestet, FHEM ist mir grade mit der Fassung v. 1710.02. (Edit: aus Beitrag 168) auch abgeschmiert, ich kann aber nicht mit Sicherheit sagen, dass es an CUL_HM liegt.
Details:
Fhem war auf dem svn-Stand von heute morgen, Neustart ohne Probleme. Dann ca. eine halbe Stunde später die betreffende CUL_HM installiert, FHEM neu gestartet. Lief erst mal alles. Eben war dann FHEMWEB nicht erreichbar, daher Neustart.
Log an der betreffenden Stelle:
2019.02.21 08:31:55 3: CUL_HM set Jalousie_Links on
Can't use string ("65") as an ARRAY ref while "strict refs" in use at ./FHEM/10_CUL_HM.pm line 10000.
2019.02.21 08:59:15 1: FritzFhemFon[6761], can´t find my parent 6759 in process list !
Died at ./FHEM/96_SIP.pm line 386.
2019.02.21 09:12:39 1: PERL WARNING: "my" variable $symbol_string masks earlier declaration in same scope at ./FHEM/99_myUtils_Homematic.pm line 78.
Das klingt eigentlich danach, als wäre CUL_HM nicht der Verursacher, sondern das SIP-Modul. Das sagt zu version: "96_SIP.pm 17070 2018-07-31 19:02:39Z Wzut"
Vor dem update hatte ich keine Probleme mit Abstürzen, das SIP-Gerät existiert - wie die CUL_HM-Geräte schon lange. FHEM hat allerdings jüngst eine ganz erhebliche Anzahl von Neustarts gehabt, weil ich die ganze Entwicklung bei MQTT2 mitbekommen wollte, kann daher nichts zum Lanzeitverhalten vorher sagen.
Hoffe, das hilft. Jetzt mache ich erst mal die Rolle rückwärts um zu sehen, ob dann dasselbe passiert.
So, habe jetzt auch vor ca. 30 min mein FHEM mal auf die aktuellste Version gehoben. Danach das Modul "10_CUL_HM.pm" aus Beitrag 168 installiert und fhem neugestartet. Mein global verbose läuft auf 3. Ich habe folgende Geräte in verschiedenen Mengen im Einsatz:
- HM-WDS10-TH-O
- HM-WDS40-TH-I
- HM-WDS40-TH-I-2
- HM-ES-PMSw1-Pl
- HM-CC-RT-DN
Ich sehe weder im syslog, noch im fhem logfile irgendwelche Fehlermeldungen.
Folgende Befehle ergeben bei mir keine Ausgaben, also alles gut (Ich weiß nicht wo dieses "mId" geloggt wird, so dass ich beide logs geprüft habe):
root@omv4:~# cat /opt/fhem/log/fhem-2019-02.log | grep mId
root@omv4:~# cat /var/log/syslog | grep mIdOder wird das nicht in den logs hinterlegt?
In meiner fhem.cfg sehe ich auch nur folgendes:
root@omv4:~# cat /opt/fhem/fhem.cfg | grep mId
attr HMUSB hmId XXXXXX
attr HMUSB2 hmId XXXXXXMeine subTypes sind auch alle noch da:
root@omv4:~# cat /opt/fhem/fhem.cfg | grep subType
attr VCCU subType virtual
attr OG_Badezimmer_Thermostat subType thermostat
attr OG_Buero_Thermostat subType thermostat
attr OG_Flur_Thermostat subType thermostat
attr OG_Kueche_Thermostat subType thermostat
attr OG_SZ_Thermostat subType thermostat
attr OG_WZ_Essbereich_Thermostat subType thermostat
attr OG_WZ_Wohnbereich_Thermostat subType thermostat
attr OG_Badezimmer_Sensor subType THSensor
attr OG_WZ_Sensor subType THSensor
attr Aussen_Nord_Sensor subType THSensor
attr Aussen_Sued_Sensor subType THSensor
attr OG2_Dachboden_Strom_Server subType powerMeter
attr OG_Badezimmer_Deckenlampe subType ctdimmer
attr OG_Badezimmer_Strahler subType ctdimmer
attr OG_Buero_Deckenlampe subType ctdimmer
attr OG_WZ_Wohnbereich_Stehlampe_oben subType extcolordimmer
attr OG_WZ_Wohnbereich_Stehlampe_mitte subType extcolordimmer
attr OG_WZ_Wohnbereich_Stehlampe_unten subType extcolordimmer
attr OG_WZ_Wohnbereich_Deckenlampe_rechts subType extcolordimmer
attr OG_WZ_Wohnbereich_Deckenlampe_links subType extcolordimmer
attr OG_WZ_Wohnbereich_Strahler_vorn subType extcolordimmer
attr OG_WZ_Wohnbereich_Strahler_hinten subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe_links subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe_mitte subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe_rechts subType extcolordimmer
attr OG_WZ_Essbereich_Boardlampe_links subType extcolordimmer
attr OG_WZ_Wohnbereich_Stehlampe subType extcolordimmer
attr OG_WZ_Wohnbereich_Deckenlampe subType extcolordimmer
attr OG_WZ_Wohnbereich_Strahler subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe subType extcolordimmer
attr OG_WZ_Essbereich_Boardlampe subType extcolordimmer
attr Roborock subType VacuumCleanerGibt es etwas, wonach ich speziell suchen soll?
Ansonsten sieht soweit erstmal alles gut aus. Alle Readings werden aktualisiert, etc. Ich melde mich heute Abend nochmal!
Ich möchte an dieser Stelle auch nochmal für die stetige Weiterentwicklung des Moduls bedanken! ;)
Viele Grüße Hoppel
Zitat von: Beta-User am 21 Februar 2019, 09:25:28
Hab's eben auch getestet, FHEM ist mir grade mit der Fassung v. 1710.02. (Edit: aus Beitrag 168) auch abgeschmiert, ich kann aber nicht mit Sicherheit sagen, dass es an CUL_HM liegt.
Details:
Fhem war auf dem svn-Stand von heute morgen, Neustart ohne Probleme. Dann ca. eine halbe Stunde später die betreffende CUL_HM installiert, FHEM neu gestartet. Lief erst mal alles. Eben war dann FHEMWEB nicht erreichbar,
Hoffe, das hilft. Jetzt mache ich erst mal die Rolle rückwärts um zu sehen, ob dann dasselbe passiert.
OK, habe das anscheinend das gleiche Problem. Ziemlich exakt eine halbe Stunde nach dem Start meines fhem Services, war dann FHEMWEB nicht mehr erreichbar. systemctl gibt mir folgenden Status:
root@omv4:~# systemctl status fhem
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2019-02-21 11:20:44 CET; 28min ago
Process: 388 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 389 (code=exited, status=255)
CPU: 20.486s
Feb 21 10:50:43 omv4 systemd[1]: Starting FHEM Home Automation...
Feb 21 10:50:43 omv4 systemd[1]: Started FHEM Home Automation.
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Main process exited, code=exited, status=255/n/a
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Unit entered failed state.
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Failed with result 'exit-code'.Wenn ich den fhem service stoppe und neu starte funktioniert FHEMWEB wieder.
Dann werde ich jetzt auch erstmal die Rolle rückwärts machen. Backup einspielen und dann erstmal nur FHEM auf die aktuellste Version updaten, um den Fehler eingrenzen zu können.
Gruß Hoppel
Das Modul "96_SIP.pm" habe ich übrigens nicht im Einsatz. Das dürfte doch dann eigentlich nicht der Fehlerverursacher sein, oder?
EDIT: Backup ist wiederhegestellt und fhem auf die aktuelle Version geupdated.
2019.02.21 12:04:06 1: update finished, "shutdown restart" is needed to activate the changes.
Mal sehen, wie es um 12:35 Uhr aussieht.
Gruß Hoppel
Zitat von: hoppel118 am 21 Februar 2019, 12:10:33
Das Modul "96_SIP.pm" habe ich übrigens nicht im Einsatz. Das dürfte doch dann eigentlich nicht der Fehlerverursacher sein, oder?
Es könnte auch irgendeine Wechselwirkung sein. Bei verbose 3 und höher müßte eigentlich was im log gestanden haben; das wäre aufschlußreicher als die systemctl-Info.
Jedenfalls läuft hier FHEM mit den aktuellsten Modulen und der svn-CUL_HM-Version seit ca. 3 Stunden vor sich hin, sieht also schon so aus, als wäre CUL_HM jedenfalls irgenwie beteiligt gewesen.
Zitat von: Beta-User am 21 Februar 2019, 12:17:03
Es könnte auch irgendeine Wechselwirkung sein. Bei verbose 3 und höher müßte eigentlich was im log gestanden haben; das wäre aufschlußreicher als die systemctl-Info.
verbose 3 habe ich. Leider aber nicht nach dem FHEMWEB-Absturz nochmal ins Log geschaut, um zu prüfen, ob da noch ein Fehler geloggt wurde, sondern direkt die Rolle rückwärts. Wenn um 12:40 Uhr noch alles läuft, spiele ich nochmal die aktuelle CUL_HM Version ein.
Zitat von: Beta-User am 21 Februar 2019, 12:17:03
Jedenfalls läuft hier FHEM mit den aktuellsten Modulen und der svn-CUL_HM-Version seit ca. 3 Stunden vor sich hin, sieht also schon so aus, als wäre CUL_HM jedenfalls irgenwie beteiligt gewesen.
Ist "svn-CUL_HM-Version" die Version aus Beitrag 168? Wenn nicht kannst du die aktuellste Version bitte nochmal hier teilen? Oder ist die aktuellste "svn-CUL_HM-Version", die die man mit dem Update erhält?
Danke und Gruß Hoppel
So, um 12:53 läuft mein FHEMWEB noch. Es scheint also tatsächlich mit der in Beitrag 168 verlinkten Version zusammenzuhängen.
Ich könnte jetzt nochmal die in Beitrag 168 verlinkte Version installieren, um zu schauen, ob der Fehler dann wieder auftritt und dann eben nochmal einen Blick ins Log werfen.
Wo soll ich genau nach Fehlern schauen? Reicht der Blick ins FHEM log? Soll ich das verbose Level auf 4 oder 5 erhöhen?
Ich werde das Update irgendwann heute Nachmittag einspielen, bzw. wenn ich Antworten auf meine Fragen habe. Vorher macht das ja nur bedingt Sinn... ;)
Gruß Hoppel
Zitat von: hoppel118 am 21 Februar 2019, 12:30:08
Ist "svn-CUL_HM-Version" die Version aus Beitrag 168? Wenn nicht kannst du die aktuellste Version bitte nochmal hier teilen? Oder ist die aktuellste "svn-CUL_HM-Version", die die man mit dem Update erhält?
Gemeint war die, die man mit dem update erhält. (Der Weg ist Entwickler läd ins svn, der Stand um kurz vor 8:00 Uhr geht ins update, individuelles FHEM holt sich, was neu ist; dabei müßte der Zeitstemple der Datei entscheidend sein).
Zitat von: hoppel118 am 21 Februar 2019, 12:30:08
verbose 3 habe ich. Leider aber nicht nach dem FHEMWEB-Absturz nochmal ins Log geschaut, um zu prüfen, ob da noch ein Fehler geloggt wurde, sondern direkt die Rolle rückwärts. Wenn um 12:40 Uhr noch alles läuft, spiele ich nochmal die aktuelle CUL_HM Version ein.
Das Log bleibt erhalten. Kannst also auch jetzt noch schauen, was um die Zeit des Absturzes rum passiert ist, auch ohne das nochmal zu provozieren.
Entscheidend sind die Zeilen vor "Server started...." (da gibt es einige Zeilen davor, die zeitlich dem Neustart zuzuordnen sind; die sind noch uninteressant; du solltest dich allg. mal mit deinem log beschäftigen, da stehen oft "interessante" Sachen drin).
Wenn du mehr zur Absturzursache wissen wolltest, wäre stacktrace das Stichwort (habe ich aber bisher auch nicht genutzt). Würde aber mal auf Martin warten, ob der schon eine Idee hat oder das anfordert (dann mache ich auch gerne die Premiere).
Zitat von: Beta-User am 21 Februar 2019, 09:25:28
2019.02.21 08:59:15 1: FritzFhemFon[6761], can´t find my parent 6759 in process list !
Died at ./FHEM/96_SIP.pm line 386.
Ich will das SIP Modul als mein Baby zwar nicht heilig sprechen , aber die Erklärung des obigen logs ist simpel:
[6761] = Es handelt sich nicht um das eigentliche Sip Device sondern um einen Child Prozess mit der PID 6791.
Der/das Child schaut wenn es ein Dauerläufer ist ( z.B. aktiver Listen Prozess ) regelmäßig ob es seine Eltern ( PID = 6759) noch gibt.
Stürzt FHEM jetzt hab sind die Eltern zwar tot das Kind lebt als Waise aber weiter. Bemerkt es diesen Umstand folgt es freiwillig mittels "Die" seiner Verwandschaft, d.h. in meinen Augen alles im grünen Bereich und wie es sein soll.
@Wzut: Danke für die Erläuterung. Gibt es dazu einen bestimmten Timeout? Zufällig ca. eine halbe Stunde? Das spräche für einen ziemlich eindeutigen Verursacher in Zeile 10000, der logauszug war nur vorne und hinten abgeschnitten, aber ansonsten an der Stelle ungekürzt:
Can't use string ("65") as an ARRAY ref while "strict refs" in use at ./FHEM/10_CUL_HM.pm line 10000.
Selstam ist nur, dass ich ein paar manuelle Schaltvorgänge testweise via FHEMWEB abgesetzt hatte, was offensichtlich auch funktioniert hat. Der fragliche war nur der letzte.
Das letzte, was ich in FHEMWEB wahrgenommen hatte, war, dass der Slider auf "on" bzw. 100% gesprungen ist; daher war ich auch zunächst davon ausgegangen, dass alles ok ist. Den Auslöser würde ich daher erst mal in der Verarbeitungslogik der Rückmeldung vom Aktor suchen.
Ergänzende Info: Es steht eine VCCU dahinter, schnellstes IO ist in der Regel ein Pi-PCB@USB (HMUARTLGW), es gibt noch einen CUL und einen Maple mit einem Transceiver im HM-Modus (der ist via LAN angebunden und typischerweise das letzte IO, das die Rückmeldung an den Server liefert). Auf dem Maple wird der erste Transceiver für HM genutzt, die anderen werden mit STACKABLE angesprochen.
Zitat von: martinp876 am 21 Februar 2019, 08:15:39
Keine Tester? Bei mir läuft es nun schon ein paar Wochen. Keine Probleme.
Das kann ich bestaetigen. Laeuft auch bei mir stabil und ohne Fehlermeldungen,
wenn auch ohne SIP-Modul mit dem aktuellen Stand:
File Rev Last Change
10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876
98_HMinfo.pm 17838 2018-11-25 10:51:09Z martinp876
00_HMUARTLGW.pm 16166 2018-02-13 19:52:08Z mgernoth
HMConfig.pm 18284 2019-01-16 18:56:58Z martinp876
Gruss Helmut
@helmut:
Ist das die Test-Version hier aus #168 oder die aus dem normalen update?
ID und Zeitstempel sind bei beiden scheinbar gleich (und die regulär verteilte funktioniert auch mit SIP bei mir bis dato gut - außerdem hat Wzut ja erläutert, dass es vermutlich nicht daran lag...)
Das mit der halben Stunde paßt allerdings recht gut auf den Aufruf in Zeile 9992 (alt: 9692), und genau an der Stelle (Zeile 10000 neu) gab es auch größere Änderungen im Code.
Als Hardwarebasis nutze ich btw. einen Atom single-Core mit Debian, Perl-Version kann ich bei Bedarf nachliefern.
Zitat von: Beta-User am 21 Februar 2019, 14:53:12
Gibt es dazu einen bestimmten Timeout?
Nun beim ausgehendem Ruf gibst du ja den Timeout selbst im Set Kommando mit an,
beim listen_mode gibt es bei erfolgreichem register am SIP Server keinen, da man ja keine Ahnung hat wann das nächste mal jemand anruft :)
Zitat von: Beta-User am 21 Februar 2019, 17:27:09
@helmut:
Ist das die Test-Version hier aus #168 oder die aus dem normalen update?
Das ist die aus dem normalen Update.
Gruss Helmut
Zitat von: Beta-User am 21 Februar 2019, 13:04:15
Gemeint war die, die man mit dem update erhält. (Der Weg ist Entwickler läd ins svn, der Stand um kurz vor 8:00 Uhr geht ins update, individuelles FHEM holt sich, was neu ist; dabei müßte der Zeitstemple der Datei entscheidend sein).
OK, dann habe ich die Datei bei mir am Laufen, die im SVN ist. Mein System läuft übrigens seit heute Mittag ohne Probleme. Falls es was neues zum Testen gibt, bin ich gern wieder dabei. Habe immer ein Backup, es kann also nichts schief gehen, toi, toi, toi. ;)
Zitat von: Beta-User am 21 Februar 2019, 13:04:15
Das Log bleibt erhalten. Kannst also auch jetzt noch schauen, was um die Zeit des Absturzes rum passiert ist, auch ohne das nochmal zu provozieren.
Entscheidend sind die Zeilen vor "Server started...." (da gibt es einige Zeilen davor, die zeitlich dem Neustart zuzuordnen sind; die sind noch uninteressant;...).
Redest du jetzt vom FHEM-log? Das bleibt bei mir nicht erhalten, um 10:50 hatte ich FHEM nach dem Update gestartet und um 11:20 Uhr ist FHEM dann abgestürzt. Folgender Auszug aus dem Log:
2019.02.20 08:30:39 3: Roborock: initialized
2019.02.21 10:39:06 2: Backup with command: tar -cf - "./certs" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem-5.8.deb" "./fhem.cfg" "./fhem.cfg.backup" "./fhem.cfg.CUL_HM" "./fhem.cfg.demo" "./fhem.cfg.save" "./fhem.pl" "./log" "./MAINTAINER.txt" "./README_DEMO.txt" "./restoreDir" "./unused" "./www" |gzip > ./backup/FHEM-20190221_103906.tar.gz
2019.02.21 12:02:31 1: Including fhem.cfg
2019.02.21 12:02:31 3: telnetPort: port 7072 opened
2019.02.21 12:02:31 3: WEB: port 8083 opened
2019.02.21 12:02:31 3: WEBphone: port 8084 openedFalls du das syslog meinst. Dort finde ich an den entscheidenden Stellen auch nicht wirklich etwas. Zwischendurch werden nur generelle Sachen der Homebrdige und des Systems allgemein geloggt...
Feb 21 10:40:30 omv4 systemd[1]: Stopping Node.js Homebridge Service...
Feb 21 10:40:30 omv4 homebridge[1542]: [2019-2-21 10:40:30] Got SIGTERM, shutting down Homebridge...
Feb 21 10:40:35 omv4 systemd[1]: homebridge-homematic.service: Main process exited, code=exited, status=143/n/a
Feb 21 10:40:35 omv4 systemd[1]: Stopped Node.js Homebridge Service.
Feb 21 10:40:35 omv4 systemd[1]: homebridge-homematic.service: Unit entered failed state.
Feb 21 10:40:35 omv4 systemd[1]: homebridge-homematic.service: Failed with result 'exit-code'.
Feb 21 10:40:38 omv4 systemd[1]: Stopping Node.js Homebridge Service...
Feb 21 10:40:38 omv4 homebridge[1590]: [2019-2-21 10:40:38] Got SIGTERM, shutting down Homebridge...
Feb 21 10:40:44 omv4 systemd[1]: homebridge-hue.service: Main process exited, code=exited, status=143/n/a
Feb 21 10:40:44 omv4 systemd[1]: Stopped Node.js Homebridge Service.
Feb 21 10:40:44 omv4 systemd[1]: homebridge-hue.service: Unit entered failed state.
Feb 21 10:40:44 omv4 systemd[1]: homebridge-hue.service: Failed with result 'exit-code'.
Feb 21 10:40:48 omv4 systemd[1]: Stopping Node.js Homebridge Service...
Feb 21 10:40:48 omv4 homebridge[1627]: [2019-2-21 10:40:48] Got SIGTERM, shutting down Homebridge...
Feb 21 10:40:53 omv4 systemd[1]: homebridge-xiaomi.service: Main process exited, code=exited, status=143/n/a
Feb 21 10:40:53 omv4 systemd[1]: Stopped Node.js Homebridge Service.
Feb 21 10:40:53 omv4 systemd[1]: homebridge-xiaomi.service: Unit entered failed state.
Feb 21 10:40:53 omv4 systemd[1]: homebridge-xiaomi.service: Failed with result 'exit-code'.
Feb 21 10:41:08 omv4 systemd[1]: Stopping FHEM Home Automation...
Feb 21 10:41:08 omv4 systemd[1]: Stopped FHEM Home Automation.
Feb 21 10:48:16 omv4 systemd[1]: Stopping FHEM Home Automation...
Feb 21 10:48:16 omv4 systemd[1]: Stopped FHEM Home Automation.
Feb 21 10:50:43 omv4 systemd[1]: Starting FHEM Home Automation...
Feb 21 10:50:43 omv4 systemd[1]: Started FHEM Home Automation.
Feb 21 11:09:01 omv4 CRON[2940]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Feb 21 11:09:04 omv4 systemd[1]: Starting Clean php session files...
Feb 21 11:09:04 omv4 systemd[1]: Started Clean php session files.
Feb 21 11:17:01 omv4 CRON[3734]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 21 11:17:19 omv4 homebridge[424]: 2019-02-21 11:17:19 caching: OG_WZ_Essbereich_Thermostat_Clima-measured-temp: 20.2
Feb 21 11:17:19 omv4 homebridge[424]: [2019-2-21 11:17:19] [FHEM] caching: CurrentTemperature: 20.2 (as number; from '20.2')
Feb 21 11:17:19 omv4 homebridge[424]: [2019-2-21 11:17:19] [FHEM] adding history entry { time: 1550744239,
Feb 21 11:17:19 omv4 homebridge[424]: setTemp: 18,
Feb 21 11:17:19 omv4 homebridge[424]: currentTemp: 20.2,
Feb 21 11:17:19 omv4 homebridge[424]: valvePosition: 0 }
Feb 21 11:17:58 omv4 homebridge[424]: 2019-02-21 11:17:58 caching: OG2_Dachboden_Strom_Server_Pwr-current: 479
Feb 21 11:17:58 omv4 homebridge[424]: [2019-2-21 11:17:58] [FHEM] caching: Custom Current: 0.47900000000000004 (as number; from '479')
Feb 21 11:17:58 omv4 homebridge[424]: 2019-02-21 11:17:58 caching: OG2_Dachboden_Strom_Server_Pwr-energy: 10951.6
Feb 21 11:17:58 omv4 homebridge[424]: [2019-2-21 11:17:58] [FHEM] caching: Custom Energy: 10.951600000000001 (as number; from '10951.6')
Feb 21 11:17:58 omv4 homebridge[424]: 2019-02-21 11:17:58 caching: OG2_Dachboden_Strom_Server_Pwr-power: 95.6
Feb 21 11:17:58 omv4 homebridge[424]: [2019-2-21 11:17:58] [FHEM] caching: Custom Power: 95.6 (as number; from '95.6')
Feb 21 11:17:58 omv4 homebridge[424]: [2019-2-21 11:17:58] [FHEM] adding history entry { time: 1550744278, power: 95.6 }
Feb 21 11:17:58 omv4 homebridge[424]: 2019-02-21 11:17:58 caching: OG2_Dachboden_Strom_Server_Pwr-voltage: 233.4
Feb 21 11:17:58 omv4 homebridge[424]: [2019-2-21 11:17:58] [FHEM] caching: Custom Voltage: 233.4 (as number; from '233.4')
Feb 21 11:19:59 omv4 homebridge[424]: 2019-02-21 11:19:59 caching: OG2_Dachboden_Strom_Server_Pwr-current: 482
Feb 21 11:19:59 omv4 homebridge[424]: [2019-2-21 11:19:59] [FHEM] caching: Custom Current: 0.482 (as number; from '482')
Feb 21 11:19:59 omv4 homebridge[424]: 2019-02-21 11:19:59 caching: OG2_Dachboden_Strom_Server_Pwr-energy: 10954.8
Feb 21 11:19:59 omv4 homebridge[424]: [2019-2-21 11:19:59] [FHEM] caching: Custom Energy: 10.954799999999999 (as number; from '10954.8')
Feb 21 11:19:59 omv4 homebridge[424]: 2019-02-21 11:19:59 caching: OG2_Dachboden_Strom_Server_Pwr-power: 95.84
Feb 21 11:19:59 omv4 homebridge[424]: [2019-2-21 11:19:59] [FHEM] caching: Custom Power: 95.84 (as number; from '95.84')
Feb 21 11:19:59 omv4 homebridge[424]: [2019-2-21 11:19:59] [FHEM] adding history entry { time: 1550744399, power: 95.84 }
Feb 21 11:19:59 omv4 homebridge[424]: 2019-02-21 11:19:59 caching: OG2_Dachboden_Strom_Server_Pwr-voltage: 232
Feb 21 11:19:59 omv4 homebridge[424]: [2019-2-21 11:19:59] [FHEM] caching: Custom Voltage: 232 (as number; from '232')
Feb 21 11:20:30 omv4 homebridge[424]: 2019-02-21 11:20:30 caching: Aussen_Nord_Sensor-temperature: 7.5
Feb 21 11:20:30 omv4 homebridge[424]: [2019-2-21 11:20:30] [FHEM] caching: CurrentTemperature: 7.5 (as number; from '7.5')
Feb 21 11:20:30 omv4 homebridge[424]: [2019-2-21 11:20:30] [FHEM] adding history entry { time: 1550744430, temp: 7.5 }
Feb 21 11:20:44 omv4 homebridge[461]: longpoll ended, reconnect in: 200msec
Feb 21 11:20:44 omv4 homebridge[424]: longpoll ended, reconnect in: 200msec
Feb 21 11:20:44 omv4 homebridge[496]: longpoll ended, reconnect in: 200msec
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Main process exited, code=exited, status=255/n/a
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Unit entered failed state.
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Failed with result 'exit-code'.
Feb 21 11:20:44 omv4 homebridge[461]: starting longpoll: https://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1550742989.392;fmt=JSON×tamp=1550744444408
Feb 21 11:20:44 omv4 homebridge[496]: starting longpoll: https://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1550744164.486;fmt=JSON×tamp=1550744444409
Feb 21 11:20:44 omv4 homebridge[424]: starting longpoll: https://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1550744434.667;fmt=JSON×tamp=1550744444409
Feb 21 11:20:44 omv4 homebridge[461]: longpoll error: Error: connect ECONNREFUSED 127.0.0.1:8083, retry in: 10000msec
Feb 21 11:20:44 omv4 homebridge[496]: longpoll error: Error: connect ECONNREFUSED 127.0.0.1:8083, retry in: 10000msec
Feb 21 11:20:44 omv4 homebridge[424]: longpoll error: Error: connect ECONNREFUSED 127.0.0.1:8083, retry in: 10000msec
Feb 21 11:20:54 omv4 homebridge[461]: starting longpoll: https://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1550742989.392;fmt=JSON×tamp=1550744454415
Feb 21 11:20:54 omv4 homebridge[496]: starting longpoll: https://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1550744164.486;fmt=JSON×tamp=1550744454416
Feb 21 11:20:54 omv4 homebridge[424]: starting longpoll: https://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1550744434.667;fmt=JSON×tamp=1550744454416
Feb 21 11:20:54 omv4 homebridge[461]: longpoll error: Error: connect ECONNREFUSED 127.0.0.1:8083, retry in: 15000msec
Feb 21 11:20:54 omv4 homebridge[496]: longpoll error: Error: connect ECONNREFUSED 127.0.0.1:8083, retry in: 15000msec
Feb 21 11:20:54 omv4 homebridge[424]: longpoll error: Error: connect ECONNREFUSED 127.0.0.1:8083, retry in: 15000msec
Zitat von: Beta-User am 21 Februar 2019, 13:04:15
du solltest dich allg. mal mit deinem log beschäftigen, da stehen oft "interessante" Sachen drin
Warum dekst du, dass ich das nicht tue? Ich beschäftige mich ziemlich häufig mit meinem Log. ;)
Zitat von: Beta-User am 21 Februar 2019, 13:04:15
Wenn du mehr zur Absturzursache wissen wolltest, wäre stacktrace das Stichwort (habe ich aber bisher auch nicht genutzt). Würde aber mal auf Martin warten, ob der schon eine Idee hat oder das anfordert (dann mache ich auch gerne die Premiere).
OK, ich warte auf Martin.
Schönen Abend noch in die Runde!
Gruß Hoppel
Zitat von: helmut am 21 Februar 2019, 19:29:43
Das ist die aus dem normalen Update.
Das ist leider nicht die Version, um die es hier geht. Meinem Verständnis nach sind die Änderungen, die die Probleme ursprünglich mal verursacht haben, im svn zurückgezogen worden. In Post
168 167 wurde die zu testende Version des Moduls gepostet. ;)
Gruß Hoppel
Zitat von: hoppel118 am 21 Februar 2019, 19:36:03
Das ist leider nicht die Version, um die es hier geht.
Du hast recht. Das hatte ich uebersehen. Wenn ich am SO Zeit finde, teste ich die aus Post 167 mal.
Gruss Helmut
Das mit der Zählweise ist schon seltsam, kommt wohl darauf an, wierum man die Beiträge anzeigt (hier: neuster oben =168).
Für mich klingt das danach, dass da ein paar statusRequest-timeouts ablaufen, ohne dass Rückmeldung erfolgt ist (habe hier einige Türkontakte, die sich nach 1800 sec. typischerweise noch nicht gemeldet haben).
Wie dem auch sei, gemeint war das FHEM-log, und das ist bei dir auch sowas von unauffällig. Nicht mal der Zeile 10.000-Hinweis... (Das mit dem log-Hinweis war dadurch motiviert, dass nur der systemctl-Auszug da war, aber nicht das FHEM-log, und das ist bei Abstürzen eigentlich immer das erste, was man sich ansehen sollte. Nix für ungut...).
@Martin: kurze Rückmeldung wäre nett, ob noch Infos benötigt werdnen
Meine Perl-Version btw.: v5.26.1 built for x86_64-linux-gnu-thread-multi
Sorry, meine antwort habe ich wohl nicht abgeschickt.
Ich vermute das Problem bei den berechnungen welche zu einem vereinfachten peering Kommando führen sollen. ist in der version eingebaut aber nicht sichtbar. Die pauschale Fehlermeldung deutet auf ein Speicher Problem oder etwas ähnliches hin.
Ich werde heute abend den Code deaktivieren und eine neue version einstellen.
sorry, dummer fehler. Hätte ich finden müssen. :-[
hat nichts mit der Umstellung auf mId zu tun. Anbei der Fix (eine Kleinigkeit - mit Wirkung
Thx. Version von heute morgen läuft seit mehr als 2,5h ohne Absturz :) .
Moin,
mein Test läuft jetzt auch. Ich war etwas zögerlich :)
Um eine schnelle Rückkehr zur ermöglichen, habe ich mal ein extra savepm Kommando gebaut. Damit sichert man die bestehende Moduldatei
savepm 10_CUL_HM.pm
Im Fehlerfall kann man relativ schnell über restore den alten Modulstand wiederherstellen.
restore list pm/zeigt die verfügbaren Stände
restore pm/YYYY-MM-DDholt den gesicherten Stand zurück. Da alles unter fhem passiert hat man keinen trouble mit Berechtigung.
Hier das define für das Kommando, den Rumpf habe ich hier (https://forum.fhem.de/index.php/topic,97725.msg909942.html#msg909942)bei Dan geklaut. ;)
define c2 cmdalias savepm .* AS {\
my ($e,$g) = (undef,(split(" ",$EVENT))[0]);;\
if (defined $g)\
{\
$e = qx(mkdir -p ./restoreDir/pm/"$year-$month-$mday"/FHEM/);;\
$e = qx(cp ./FHEM/$g ./restoreDir/pm/"$year-$month-$mday"/FHEM/)\
} else {\
$e = "use savepm Filename inside ./FHEM/"\
}\
return $e ? $e : "done"\
}
Gruß Otto
Kurze Zwischeninfo: Lief bis heute Mittag problemfrei.
Da ich ganz sicher gehen wollte, dass ich auch wirklich mit der Version hier unterwegs bin (ich hatte das nach dem Reinkopieren des neuen Codes nur über reload gemacht), habe ich vorhin doch nochmal FHEM neu gestartet. Läuft wieder seit mehr als 1800 Sekunden :) . (@Martin, kleine Anregung: ich hatte das gestern eher nebenbei erledigt und wollte dann nachsehen, ob ich grade auch wirklich die richtige Version teste. Aber leider hat die Abfrage über "version" da nicht für erhellende Info gesorgt (da gibt es keinen Unterschied, jedenfalls ist die Revisions-Nummerierung im svn identisch), sonst hätte ich das jetzt im Dauertest weiter laufen lassen; so gab's halt gleich noch ein update von remote (da war aber CUL_HM nicht bei)...)
@Otto: Netter Code, da setze ich mir doch gleich ein Lesezeichen drauf :) .
Zitat von: martinp876 am 24 Februar 2019, 10:35:29
Anbei der Fix (eine Kleinigkeit - mit Wirkung
Laeuft bei mir seit ungefaehr vier Stunden ohne jedes Problem.
Gruss Helmut
Update: Meine HM-TC-IT-WM-W-EU machen doch Probleme.
"rp2 fhem45"> l if_wohnzimmer
Internals:
.lastTimeActivity 1551100800.73665
.lastTimeCommandAccepted 1551100438.07684
.lastTimeD-firmware 1551100800.73665
.lastTimeD-serialNr 1551100800.73665
.lastTimePairedTo 1551100438.63701
.lastTimeR-pairCentral 1551100800.73665
.lastTimeRegL_00. 1551100438.62609
.lastTimebattery 1551104522.57714
.lastTimebatteryLevel 1551104522.57714
.lastTimedesired-temp 1551104522.57714
.lastTimemeasured-temp 1551104522.57714
.lastTimestate 1551100801.43511
.triggerUsed 1
CFGFN config/innenfuehler.cfg
CUL1_MSGCNT 350
CUL1_RAWMSG A0CCC84703208D700000000CA27::-70.5:CUL1
CUL1_RSSI -70.5
CUL1_TIME 2019-02-25 15:22:12
CUL2_MSGCNT 350
CUL2_RAWMSG 05000030CC84703208D700000000CA27
CUL2_RSSI -48
CUL2_TIME 2019-02-25 15:22:12
DEF 3208D7
FUUID 5c73ac6f-f33f-053c-128e-861b8b63f7f7939b
IODev CUL2
LASTInputDev CUL2
MSGCNT 700
NAME if_wohnzimmer
NOTIFYDEV global
NR 447
NTFY_ORDER 50-if_wohnzimmer
STATE CMDs_done
TYPE CUL_HM
channel_01 if_wohnzimmer_Weather
channel_02 if_wohnzimmer_Climate
channel_03 if_wohnzimmer_WindowRec
channel_06 if_wohnzimmer_remote
channel_07 if_wohnzimmer_SwitchTr
lastMsg No:CC - t:70 s:3208D7 d:000000 00CA27
protLastRcv 2019-02-25 15:22:12
protRcv 351 last_at:2019-02-25 15:22:12
protSnd 65 last_at:2019-02-25 14:24:06
protSndB 1 last_at:2019-02-25 14:13:57
protState CMDs_done
rssi_at_CUL1 cnt:350 min:-90 max:-62.5 avg:-70.3 lst:-70.5
rssi_at_CUL2 cnt:350 min:-76 max:-46 avg:-50.27 lst:-48
.attraggr:
.attreocr:
.*
.attrminint:
.*:3600
Helper:
DBLOG:
battery:
bath45DbLog:
TIME 1551104522.60408
VALUE ok
batteryLevel:
bath45DbLog:
TIME 1551104522.60408
VALUE 2.7
READINGS:
2019-02-25 14:20:00 .D-devInfo 03FFFF
2019-02-25 14:20:00 .D-stc 58
2018-09-21 13:58:13 .R-btnLock off
2018-09-21 13:58:13 .R-globalBtnLock off
2018-09-21 13:58:13 .R-localResDis off
2018-09-21 13:58:13 .R-lowBatLimitRT 2.2 V
2018-09-21 13:58:13 .R-modusBtnLock off
2018-09-21 13:58:13 .peerListRDate 2018-09-21 13:58:13
2019-02-25 15:22:12 .protLastRcv 2019-02-25 15:22:12
2018-09-22 13:28:19 1 10.2
2019-02-25 14:20:05 Activity alive
2019-02-25 14:20:01 CommandAccepted yes
2019-02-25 14:20:00 D-firmware 1.3
2019-02-25 14:20:00 D-serialNr LEQ0997391
2019-02-25 14:13:58 PairedTo 0x720902
2018-09-21 13:58:13 R-burstRx on
2018-09-21 13:58:13 R-cyclicInfoMsg on
2018-09-21 13:58:13 R-cyclicInfoMsgDis 0
2019-02-25 14:20:00 R-pairCentral set_0x720902
2018-09-21 13:58:14 R-sign off
2019-02-25 14:14:50 RegL_07.
2019-02-25 09:07:37 absoluteHumidity 6.6
2019-02-25 15:22:02 battery ok
2019-02-25 15:22:02 batteryLevel 2.7
2019-02-25 09:07:27 boostTime -
2019-02-25 09:07:27 commReporting off
2019-02-25 09:07:27 controlMode auto
2019-02-25 15:22:02 desired-temp 17.0
2019-02-25 09:07:37 dewpoint 5.3
2019-02-25 09:50:35 humidity 38
2019-02-25 15:22:02 measured-temp 20.2
2019-02-25 14:24:06 state CMDs_done
2019-02-25 09:50:35 temperature 20.1
2019-02-25 09:07:27 winOpenReporting off
helper:
HM_CMDNR 204
PONtest 1
cSnd 017209023208D7000802010A720B090C02,017209023208D70006
mId 00AD
peerFriend
peerOpt -:thermostat
regLst 0
rxType 6
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
lRcTm 29968952
lstRecType 70
newChn +3208D7,00,00,00
nextSend 1551104532.68404
nxtSndMcnt CC
prefIO
rxt 0
tgtDly 120
vccu VCCU
p:
3208D7
00
00
00
mRssi:
mNo CC
io:
CUL1:
-70.5
-70.5
CUL2:
-40
-40
prt:
awake 0
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
rssi:
at_CUL1:
avg -70.3042857142857
cnt 350
lst -70.5
max -62.5
min -90
at_CUL2:
avg -50.2714285714286
cnt 350
lst -48
max -46
min -76
shRegW:
07 02
shadowReg:
tmpl:
Attributes:
.mId 00AD
DbLogInclude temperature,humidity,dewpoint,absoluteHumidity,battery.*
IODev CUL1
IOgrp VCCU:CUL1
actCycle 012:00
actStatus alive
autoReadReg 0_off
event-min-interval .*:3600
event-on-change-reading .*
expert 2_full
firmware 1.3
group Thermometer
model HM-TC-IT-WM-W-EU
msgRepeat 1
room Erdgeschoss->Wohnzimmer->Devices
serialNr LEQ0997391
subType thermostat
verbose 5
webCmd getConfig:clear msgEvents"rp2 fhem45"> inf timer if_wohnzimmer.*
"rp2 fhem45"> 2019-02-25 15:26:16.325 CUL_HM if_wohnzimmer_Climate desired-temp: 17.0
2019-02-25 15:26:16.325 CUL_HM if_wohnzimmer_Climate humidity: 39
2019-02-25 15:26:16.325 CUL_HM if_wohnzimmer_Climate measured-temp: 20.2
2019-02-25 15:26:16.325 CUL_HM if_wohnzimmer_Climate T: 20.2 desired: 17.0
2019-02-25 15:26:36.108 CUL_HM if_wohnzimmer_Weather humidity: 39
2019-02-25 15:26:36.108 CUL_HM if_wohnzimmer_Weather T: 20.2 H: 39
2019-02-25 15:26:36.108 CUL_HM if_wohnzimmer_Weather temperature: 20.2
2019-02-25 15:26:36.108 CUL_HM if_wohnzimmer_Weather absoluteHumidity: 6.8
2019-02-25 15:26:36.108 CUL_HM if_wohnzimmer_Weather dewpoint: 5.8$ tail -f /opt/fhem/log/fhem-2019-02.log|grep if_wohnzimmer
2019.02.25 15:26:16.332 4: CUL_HM if_wohnzimmer dupe: dont process
2019.02.25 15:26:36.118 4: CUL_HM if_wohnzimmer dupe: dont process
Bei den anderen sieht das gleich aus.
Ein HM-CC-TC zeigt mit verbose 5 auch die Duplicates im Log an, aber die Werte wie
Temperatur, Feuchte usw. werden in den Readings aktualisiert.
Gruss Helmut
2. Update: Die Duplicates kommen von meinem zweiten CUL.
Darauf haette ich eben schon kommen koennen.
Aber jetzt bin ich mit dem 10_CUL_HM.pm zurueckgegangen und erwartungsgemaess
funktioniert wieder alles. In der telnet-Konsole sehe ich nun die Meldungen vom
Device, nicht dessen Kanaelen:
"rp2 fhem45"> inf timer if_wohnzimmer.*
"rp2 fhem45"> 2019-02-25 17:20:42.929 CUL_HM if_wohnzimmer measured-temp: 19.7
2019-02-25 17:20:42.929 CUL_HM if_wohnzimmer T: 19.7 desired: 21.0
2019-02-25 17:21:02.953 CUL_HM if_wohnzimmer T: 19.7 H: 41
2019-02-25 17:21:02.953 CUL_HM if_wohnzimmer temperature: 19.7
2019-02-25 17:21:02.953 CUL_HM if_wohnzimmer absoluteHumidity: 6.9
2019-02-25 17:21:02.953 CUL_HM if_wohnzimmer dewpoint: 6.1 Auch bei den Internals tauchen die Kanaele im Listing nicht mehr auf:
"rp2 fhem45"> l if_wohnzimmer
Internals:
.lastTimeActivity 1551107577.40094
.lastTimePairedTo 1551111980.85102
.lastTimeR-pairCentral 1551111980.85175
.lastTimeRegL_00. 1551111980.83996
.lastTimeRegL_01. 1551111981.52495
.lastTimeabsoluteHumidity 1551111662.92217
.lastTimebattery 1551108903.63088
.lastTimebatteryLevel 1551108903.63088
.lastTimeboostTime 1551108903.63088
.lastTimecommReporting 1551108903.63088
.lastTimecontrolMode 1551108903.63088
.lastTimedesired-temp 1551110443.1568
.lastTimedewpoint 1551111662.92217
.lastTimehumidity 1551111807.91411
.lastTimemeasured-temp 1551111642.91
.lastTimestate 1551111979.78231
.lastTimetemperature 1551111662.91157
.lastTimewinOpenReporting 1551108903.63088
.triggerUsed 1
CFGFN config/innenfuehler.cfg
CUL1_MSGCNT 66
CUL1_RAWMSG A0E0180103208D77209020208000000::-70.5:CUL1
CUL1_RSSI -70.5
CUL1_TIME 2019-02-25 17:26:21
CUL2_MSGCNT 66
CUL2_RAWMSG 050100300180103208D77209020208000000
CUL2_RSSI -48
CUL2_TIME 2019-02-25 17:26:21
DEF 3208D7
FUUID 5c7405ea-f33f-053c-3ed3-c58c7bd6e91f831f
IODev CUL2
LASTInputDev CUL2
MSGCNT 132
NAME if_wohnzimmer
NOTIFYDEV global
NR 447
NTFY_ORDER 50-if_wohnzimmer
STATE T: 19.7 H: 41
TYPE CUL_HM
lastMsg No:01 - t:10 s:3208D7 d:720902 0208000000
protLastRcv 2019-02-25 17:26:21
protRcv 66 last_at:2019-02-25 17:26:21
protSnd 4 last_at:2019-02-25 17:26:21
protSndB 1 last_at:2019-02-25 17:26:19
protState CMDs_done
rssi_at_CUL1 cnt:66 min:-72 max:-68 avg:-70.1 lst:-70.5
rssi_at_CUL2 cnt:66 min:-48 max:-47 avg:-47.37 lst:-48
.attraggr:
.attreocr:
.*
.attrminint:
.*:3600
Helper:
DBLOG:
absoluteHumidity:
bath45DbLog:
TIME 1551111662.93017
VALUE 6.9
battery:
bath45DbLog:
TIME 1551108903.67609
VALUE ok
batteryLevel:
bath45DbLog:
TIME 1551108903.67609
VALUE 2.7
dewpoint:
bath45DbLog:
TIME 1551111662.93017
VALUE 6.1
humidity:
bath45DbLog:
TIME 1551111807.92516
VALUE 41
temperature:
bath45DbLog:
TIME 1551111662.93017
VALUE 19.7Gruss Helmut
Hallo Martin,
bei mir läuft bisher alles unauffällig. ;)
Gruß Otto
1) cooles modul, Otto. Allerdings nicht vergessen das setup zu sichern. In dieser version wird nichts kaputt gemacht, allerdings das setup erweitert. Ggf einfach ein restart ohne save vorher.
2) mit dem tc bin ich abgehängt. Absoluthumidity kenne ich nicht. Temperature ist am weather channel. Measured-temp am climate. Hast du die readings verbogen? Wäre interesant wie, damit ich es ggf berücksichtigt kann
Danke für die tests. Am Wochenende wird es aktiviert.
Zitat von: martinp876 am 25 Februar 2019, 20:51:10
1) cooles modul, Otto. Allerdings nicht vergessen das setup zu sichern. In dieser version wird nichts kaputt gemacht, allerdings das setup erweitert. Ggf einfach ein restart ohne save vorher.
Erklärst Du mir das? Ich sehe ehrlich bisher keine Auswirkungen.
Ich habe auch nicht nur reload gemacht sondern einmal neu gestartet.
Es gibt bisher keine Fehler, es funktioniert soweit alles. Speicher verhält sich unauffällig.
Gruß Otto
Zitat von: martinp876 am 25 Februar 2019, 20:51:10
2) mit dem tc bin ich abgehängt. Absoluthumidity kenne ich nicht. Temperature ist am weather channel. Measured-temp am climate. Hast du die readings verbogen? Wäre interesant wie, damit ich es ggf berücksichtigt kann
Der TC verhaelt sich auch mit der Version aus #191 wie vorher - obwohl
ich auch bei diesem die Kanaele aus der Konfig geloescht habe weil mir das
Haupt-Device alle Infos liefert die ich haben moechte.
Die Readings habe ich in Ruhe gelassen, das waere bei dem vollstaendigen
Listing ja auch zu sehen, oder gibt es einen anderen Weg den ich nicht kenne?
absoluteHumidity kannst Du mit einem Attribut des dewpoint-Moduls berechnen
lassen.
Wenn ich den Weather-Channel wieder anlegen muss, ist das fuer mich auch in
Ordnung.
Grusss Helmut
Hallo
Ich habe mir erlaut das Sichern der fhem.cfg mit einzubauen...
Ich hoffe das ist OK für Dich Otto?!
savepm .* AS {
my ($e,$g) = (undef,(split(" ",$EVENT))[0]);
if (defined $g)
{
$e = qx(mkdir -p ./restoreDir/pm/"$year-$month-$mday"/FHEM/);
$e = qx(cp ./FHEM/$g ./restoreDir/pm/"$year-$month-$mday"/FHEM/);
$e = qx(cp ./fhem.cfg ./restoreDir/pm/"$year-$month-$mday"/)
} else {
$e = "use savepm Filename inside ./FHEM/"
}
return $e ? $e : "done"
}
bzw. als RAW
defmod cmd_modulsave cmdalias savepm .* AS {\
my ($e,$g) = (undef,(split(" ",$EVENT))[0]);;\
if (defined $g)\
{\
$e = qx(mkdir -p ./restoreDir/pm/"$year-$month-$mday"/FHEM/);;\
$e = qx(cp ./FHEM/$g ./restoreDir/pm/"$year-$month-$mday"/FHEM/);;\
$e = qx(cp ./fhem.cfg ./restoreDir/pm/"$year-$month-$mday"/)\
} else {\
$e = "use savepm Filename inside ./FHEM/"\
}\
return $e ? $e : "done"\
}
attr cmd_modulsave comment Sichern:\
savepm <modulname> | savepm 10_CUL_HM.pm\
Anzeigen:\
restore list pm/\
Wiederherstellen:\
restore pm/YYYY-MM-DD
Zitat von: Otto123 am 25 Februar 2019, 10:39:26
Um eine schnelle Rückkehr zur ermöglichen, habe ich mal ein extra savepm Kommando gebaut. Damit sichert man die bestehende Moduldatei
Zitat von: DoubleD am 26 Februar 2019, 20:52:28
Ich habe mir erlaut das Sichern der fhem.cfg mit einzubauen...
Ich hoffe das ist OK für Dich Otto?!
Hallo Otto und Double,
ich bin hier das arme Würstchen - und habe ja auch Ärger mit CUL_HM.
Ich nehme an, dass es möglich ist, das alles als einen Link mit in die linke Navi-Leite von FHEM/Web zu nehmen. Es wäre sehrsehrsehr freundlich, den
kompletten Code dafür (nur Sicherung 10_Cul_HM + save fhem) hier zu veröffentlichen - damit ich das bei mir einbauen kann (und dabei keine Fehler mache). Das würde sicher nicht nur mich freuen.
Sehr herzlichen Dank!
Hallo Curt,
ich weiß nicht was Du meinst. Mein kompletter Code ist veröffentlicht und sichert eine oder mehrere Dateien im Pfad ./FHEM.
Zitatsave fhem
ist für mich backup - das existiert so im System.
Also warum fühlst Du dich als armes Würstchen? :-\
Gruß Otto
Hallo Otto
Der neue Code basiert darauf die devices anhand der mid zu identigizieren, nicht mehr des attr model.
Technisch identische typen werden über die id und das alias gleichgeschaltet. Das vereinfacht den Code und wird noch ein paar Aufräumarbeiten in HMconfig nach sich ziehen.
Attr mid und .mid werden abfelegt. Die attribute werden bei der Migration automatisch erzeugt.
Speichert man also die config ist das erledigt. Die migration ist abgeschlossen. Wenn es fehlerfrei war ist alles gut. Wenn ein Fehler drin ist, ist er drin. Sieht also gut aus.
Zur Sicherheit wird das ändern dieser attribute verweigert.
Geht nur noch durch die Hintertür
ZitatDie attribute werden bei der Migration automatisch erzeugt.
Und wenn ich solche Attribute nicht habe/sehe?
Dann
- hast du nicht gründlich geschaut (showinternalvalues)
- hast du nicht die korrekte Version
- hast du nicht gebootet
- habe ich einen bug
showinternalvalues - habe ich nicht. Nicht bei set nicht bei get und nicht bei attr oder ich sehe es einfach nicht.
Ich habe die Version aus #190
Ich habe gebootet
...
was soll ich ermitteln?
das attribut gibt es im modul global.
Sorry, bei dir als alter Hase hatte ich angenommen, das attr ist dir geläufig. Insbesondere da culhm doch einiges unsichtbar schaltet.
jetzt ist es "hell" ;D
list .* .mId
FB12 0029
FensterAZL 00C7
FensterAZR 00C7
FensterBDu 00C7
FensterBOg 0030
FensterGZL 00C7
FensterGZR 00C7
FensterKL 00C7
FensterKR 00C7
FensterSZ 00C7
FensterWZR 00C7
HM_33980B 00BE
HM_4C1BB8 00C7
HM_535F7A 0019
HM_53F520 00A6
HzgAkDecke 0004
HzgAkSchraege 0004
HzgAzGaube 0004
HzgAzSchraege 0004
HzgAzSpitze 0004
HzgGzDecke 0004
HzgGzGaube 0004
HzgGzSchraege 0004
LichtBWa 0052
LichtGaDecke 0004
LichtKuL 006C
LichtKuR 006C
LichtSz 0069
LichtWzLO 0069
LichtWzLU 0069
LichtWzR 0068
PIR1 004F
PIR3 004F
PIRFront 004F
PIRWg 005D
PSD1 00AC
PSD2 00AC
PSD3 00AC
RC41 003B
RC42 00A0
RC61 00A9
RC62 00A9
RC81 00D9
RmAZ 0042
RmFlur 0042
RmSZ 0042
RolloAK 0005
RolloAZL 0005
RolloAZLL 0005
RolloAZR 0005
RolloBDu 0053
RolloBWa 0053
RolloGZL 0005
RolloGZR 0005
RolloKUL 006A
RolloKUR 006A
RolloSZ 0005
RolloWZL 0005
RolloWZR 0005
SD1 0011
SD2 0011
SD3 0011
SD4 0011
SW01 0009
SW1 0061
SW2 0061
SW3 00AB
SW81 00BE
Schalter3 0046
SensorAK 003F
SensorAussen 003D
SensorDiff 00A8
SensorGZ 00AD
SensorKE 003F
SensorR1 00AD
SensorR2 00AD
SensorWG 003F
Taster4_01 0034
TasterDIS 0060
TeamDev1 FFF1
VCCU FFF0Man lernt halt nie aus ;)
Hallo Martin,
deviceRename fehlt in der neuen Version?
Ansonsten läuft alles immer noch ohne Störung.
Gruß Otto
Heute Update eingespielt:
< # $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $
> # $Id: 10_CUL_HM.pm 18761 2019-02-28 18:43:17Z martinp876 $
Danach war der ActionDetector und der Selbstbau-Ultraschall-Homematic nicht mehr vorhanden.
Ein Restore des alten Modules führte zu den bekannten attr .mID Fehlern, dafür waren der ActionDetector und Ultraschall wieder mit subType 1 vorhanden.
Danke, -MN
Ich will nochmals erwähnen, dass sich meine drei Rauchmelder noch nicht wieder von der letzten Aktion erholten.
Mein ActionDetector ist immernoch vorhanden.
Ich werde HMConfig updaten damit auch der AgtionDetector eine ID bekommt.
Die selbstbau sensoren sollten funktionieren, wenn sie korrekt eingetragen sind. Meine sind vorhanden. Den Ultraschall Sensor haben ich nicht.
Nicht mehr vorhanden verstehe ich nicht. Nach einem List war das Device nicht mehr vorhanden? schicke mir ein List des Device.
Zu den Rauchmeldern kann ich so nichts sagen, ausser dass du in #201 ein armes würstchen bist und nie Fehler machst. Den Code hast du sicher schon - und sicher auch schon fehlerfrei implementiert. Leider habe ich nicht gefunden, was deine RMs nun nicht korrekt machen. Somit kann ich keine Aussage treffen.
Hi Martin,
Danke für Deine Antwort. Nach dem Update waren der ActionDetector und der Ultraschallsensor in keinem Raum mehr zu finden (auch nicht in Unsorted, Everything, usw.). Jedoch konnte ich die Definitionen mit configdb search %Detector% noch finden und sehen.
Hier die Lists:
Internals:
CHANGED
DEF 000000
FUUID 5c57001c-f33f-4ba1-9dc3-40140f6d1f55c418
IODev
NAME ActionDetector
NOTIFYDEV global
NR 21
NTFY_ORDER 50-ActionDetector
STATE alive:58 dead:0 unkn:0 off:0
TYPE CUL_HM
READINGS:
2019-03-01 20:24:02 state alive:58 dead:0 unkn:0 off:0
2019-03-01 20:24:02 status_HM_AUSSEN.ATELIER_Motion alive
2019-03-01 20:24:02 status_HM_AUSSEN.CARPRT_Motion alive
2019-03-01 20:24:02 status_HM_AUSSEN.MNDOOR_Motion alive
2019-03-01 20:24:02 status_HM_AUSSEN.Scheune_Weather alive
2019-03-01 20:24:02 status_HM_EG.ARBEITZ_FensterLinks alive
2019-03-01 20:24:02 status_HM_EG.ARBEITZ_HeizungLinks alive
2019-03-01 20:24:02 status_HM_EG.ARBEITZ_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.ATELIER_TuerLinks alive
2019-03-01 20:24:02 status_HM_EG.ATELIER_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.ATELIER_WarmWasserPwmSw alive
2019-03-01 20:24:02 status_HM_EG.ESSZMMR_FensterMitte alive
2019-03-01 20:24:02 status_HM_EG.ESSZMMR_HeizungLinks alive
2019-03-01 20:24:02 status_HM_EG.ESSZMMR_HeizungMitte alive
2019-03-01 20:24:02 status_HM_EG.ESSZMMR_HeizungRechts alive
2019-03-01 20:24:02 status_HM_EG.ESSZMMR_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.FLUREIN_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.FLURTRE_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.FLUR_TagStrom alive
2019-03-01 20:24:02 status_HM_EG.FLUR_TuerEingang alive
2019-03-01 20:24:02 status_HM_EG.GAESTEZ_FensterLinksUnten alive
2019-03-01 20:24:02 status_HM_EG.GAESTEZ_Heizung alive
2019-03-01 20:24:02 status_HM_EG.GAESTEZ_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.GARDERO_Fenster alive
2019-03-01 20:24:02 status_HM_EG.GARDERO_Heizung alive
2019-03-01 20:24:02 status_HM_EG.GARDERO_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.HAUSWWR_Fenster alive
2019-03-01 20:24:02 status_HM_EG.HAUSWWR_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.KELLER_GasCounter alive
2019-03-01 20:24:02 status_HM_EG.KELLER_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.KUECHE_FensterRechts alive
2019-03-01 20:24:02 status_HM_EG.KUECHE_HeizungLinks alive
2019-03-01 20:24:02 status_HM_EG.KUECHE_HeizungRechts alive
2019-03-01 20:24:02 status_HM_EG.KUECHE_Kuehlschrank alive
2019-03-01 20:24:02 status_HM_EG.KUECHE_Wandthermostat alive
2019-03-01 20:24:02 status_HM_EG.WINTERG_Heizung alive
2019-03-01 20:24:02 status_HM_EG.WINTERG_Terrassentuer alive
2019-03-01 20:24:02 status_HM_EG.WINTERG_Wandthermostat alive
2019-03-01 20:24:02 status_HM_OG.BADEZMR_Wandthermostat alive
2019-03-01 20:24:02 status_HM_OG.BADEZM_FensterLinks alive
2019-03-01 20:24:02 status_HM_OG.BADEZM_FensterRechts alive
2019-03-01 20:24:02 status_HM_OG.FLUR_Wandthermostat alive
2019-03-01 20:24:02 status_HM_OG.INEARBEIT_Heizung alive
2019-03-01 20:24:02 status_HM_OG.INEARBEIT_Wandthermostat alive
2019-03-01 20:24:02 status_HM_OG.INESCHLA_FensterRechts alive
2019-03-01 20:24:02 status_HM_OG.INESCHLA_Heizung alive
2019-03-01 20:24:02 status_HM_OG.INESCHLA_Wandthermostat alive
2019-03-01 20:24:02 status_HM_OG.LENNART_FensterLinks alive
2019-03-01 20:24:02 status_HM_OG.LENNART_FensterRechts alive
2019-03-01 20:24:02 status_HM_OG.LENNART_Wandthermostat alive
2019-03-01 20:24:02 status_HM_OG.SCHLAFZ_FensterRechts alive
2019-03-01 20:24:02 status_HM_OG.SCHLAFZ_HeizungLinks alive
2019-03-01 20:24:02 status_HM_OG.SCHLAFZ_HeizungMitte alive
2019-03-01 20:24:02 status_HM_OG.SCHLAFZ_HeizungRechts alive
2019-03-01 20:24:02 status_HM_OG.SCHLAFZ_Wandthermostat alive
2019-03-01 20:24:02 status_HM_OG.WOHNZMR_FensterRechts alive
2019-03-01 20:24:02 status_HM_OG.WOHNZMR_HeizungLinks alive
2019-03-01 20:24:02 status_HM_OG.WOHNZMR_HeizungRechts alive
2019-03-01 20:24:02 status_HM_OG.WOHNZMR_Wandthermostat alive
helper:
HM_CMDNR 131
actCycle 600
mId
peers 286865,2ACB06,2AD91F,2BBF6C,2C9869,2C9B54,2C9BF9,2CA4D9,2E1DC0,2E61DA,2E96A1,2EEF8A,301F53,30281F,313583,31358B,314230,314307,31D1FD,31DA16,31DA8C,31FF57,32699B,34AFFC,34B24B,35A426,35C61D,35EB59,36821F,37008D,375D5E,38E43B,38E510,38E511,38F0FF,3BD11A,3BD1F4,3F2D76,3F2DCE,3F2E6A,3FB679,3FB8BF,43C2F8,44ED4B,44EEB2,44FEA4,45786F,45EBEB,50E2F0,55F9C6,57BB53,58AF99,5E08D9,5E0D7E,5E144B,603009,659A5A,68261B
286865:
start 2019-03-01 18:54:01
2ACB06:
start 2019-03-01 18:54:01
2AD91F:
start 2019-03-01 18:54:01
2BBF6C:
start 2019-03-01 18:54:01
2C9869:
start 2019-03-01 18:54:01
2C9B54:
start 2019-03-01 18:54:01
2C9BF9:
start 2019-03-01 18:54:01
2CA4D9:
start 2019-03-01 18:54:01
2E1DC0:
start 2019-03-01 18:54:01
2E61DA:
start 2019-03-01 18:54:01
2E96A1:
start 2019-03-01 18:54:01
2EEF8A:
start 2019-03-01 18:54:01
301F53:
start 2019-03-01 18:54:01
30281F:
start 2019-03-01 18:54:01
313583:
start 2019-03-01 18:54:01
31358B:
start 2019-03-01 18:54:01
314230:
start 2019-03-01 18:54:01
314307:
start 2019-03-01 18:54:01
31D1FD:
start 2019-03-01 18:54:02
31DA16:
start 2019-03-01 18:54:01
31DA8C:
start 2019-03-01 18:54:01
31FF57:
start 2019-03-01 18:54:01
32699B:
start 2019-03-01 18:54:01
34AFFC:
start 2019-03-01 18:54:01
34B24B:
start 2019-03-01 18:54:01
35A426:
start 2019-03-01 18:54:01
35C61D:
start 2019-03-01 18:54:01
35EB59:
start 2019-03-01 18:54:01
36821F:
start 2019-03-01 18:54:01
37008D:
start 2019-03-01 18:54:01
375D5E:
start 2019-03-01 18:54:01
38E43B:
start 2019-03-01 18:54:01
38E510:
start 2019-03-01 18:54:01
38E511:
start 2019-03-01 18:54:01
38F0FF:
start 2019-03-01 18:54:01
3BD11A:
start 2019-03-01 18:54:01
3BD1F4:
start 2019-03-01 18:54:01
3F2D76:
start 2019-03-01 18:54:01
3F2DCE:
start 2019-03-01 18:54:01
3F2E6A:
start 2019-03-01 18:54:01
3FB679:
start 2019-03-01 18:54:01
3FB8BF:
start 2019-03-01 18:54:01
43C2F8:
start 2019-03-01 18:54:01
44ED4B:
start 2019-03-01 18:54:01
44EEB2:
start 2019-03-01 18:54:01
44FEA4:
start 2019-03-01 18:54:01
45786F:
start 2019-03-01 18:54:01
45EBEB:
start 2019-03-01 18:54:01
50E2F0:
start 2019-03-01 18:54:01
55F9C6:
start 2019-03-01 18:54:01
57BB53:
start 2019-03-01 18:54:01
58AF99:
start 2019-03-01 18:54:01
5E08D9:
start 2019-03-01 18:54:01
5E0D7E:
start 2019-03-01 18:54:01
5E144B:
start 2019-03-01 18:54:01
603009:
start 2019-03-01 18:54:01
659A5A:
start 2019-03-01 18:54:01
68261B:
start 2019-03-01 18:54:01
io:
newChn +000000,00,00,00
prefIO
rxt 0
vccu
p:
000000
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
tmpl:
Attributes:
event-on-change-reading .*
model ActionDetector
room SYS_Backend,SYS_HomeMatic
und
Internals:
DEF 444008
FUUID 5c585d8a-f33f-4ba1-cdce-46947cfb2a0ebc8b
HM_HMLAN1_MSGCNT 2
HM_HMLAN1_RAWMSG E444008,0000,830BAD3D,FF,FFB2,8CA2534440081A2B3C010200001D
HM_HMLAN1_RSSI -78
HM_HMLAN1_TIME 2019-03-01 20:05:00
HM_HMLAN2_MSGCNT 1
HM_HMLAN2_RAWMSG 050100478CA2534440081A2B3C010200001D
HM_HMLAN2_RSSI -71
HM_HMLAN2_TIME 2019-03-01 20:05:00
HM_HMLAN3_MSGCNT 1
HM_HMLAN3_RAWMSG 050000468CA2534440081A2B3C010200001D
HM_HMLAN3_RSSI -70
HM_HMLAN3_TIME 2019-03-01 20:05:00
IODev HM_HMLAN2
LASTInputDev HM_HMLAN3
MSGCNT 4
NAME HM_AUSSEN.Teichhoehe
NOTIFYDEV global
NR 349
NTFY_ORDER 50-HM_AUSSEN.Teichhoehe
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_AUSSEN.Teichhoehe_Values
lastMsg No:8C - t:53 s:444008 d:1A2B3C 010200001D
protLastRcv 2019-03-01 20:05:00
protRcv 2 last_at:2019-03-01 20:05:00
rssi_at_HM_HMLAN1 cnt:2 min:-80 max:-78 avg:-79 lst:-78
rssi_at_HM_HMLAN2 cnt:1 min:-71 max:-71 avg:-71 lst:-71
rssi_at_HM_HMLAN3 cnt:1 min:-70 max:-70 avg:-70 lst:-70
READINGS:
2018-08-15 14:53:25 CommandAccepted yes
2018-08-15 14:53:24 D-firmware 0.2
2018-08-15 14:53:24 D-serialNr FHEM444008
2018-08-15 14:46:03 PairedTo 0x1A2B3C
2018-08-15 14:46:03 R-pairCentral 0x1A2B3C
2018-08-15 14:46:03 RegL_00. 0A:1A 0B:2B 0C:3C 00:00
2018-08-15 14:45:43 sabotageAttack_ErrIoAttack cnt 1
2019-02-04 15:52:01 state CMDs_done
helper:
HM_CMDNR 140
mId
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +444008,00,00,00
nextSend 1551467100.81705
rxt 0
vccu VCCU
p:
444008
00
00
00
prefIO:
HM_HMLAN2
mRssi:
mNo 8C
io:
HM_HMLAN1:
-78
-78
HM_HMLAN2:
-69
-69
HM_HMLAN3:
-70
-70
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
rssi:
at_HM_HMLAN1:
avg -79
cnt 2
lst -78
max -78
min -80
at_HM_HMLAN2:
avg -71
cnt 1
lst -71
max -71
min -71
at_HM_HMLAN3:
avg -70
cnt 1
lst -70
max -70
min -70
tmpl:
Attributes:
IODev HM_HMLAN2
IOgrp VCCU:HM_HMLAN2
autoReadReg 4_reqStatus
expert 2_raw
firmware 0.2
model HB-GEN-SENS
room Aussen,SYS_HomeMatic
serialNr FHEM444008
webCmd getConfig:clear msgEvents
Ich hatte nach dem Update auch versucht, einen neuen Unterputz-Aktor anzulernen - das scheiterte, bzw. das anlernen war nicht möglich. Hab ich aber nicht weiter verfolgt, meine Regierung ist auch ohne Funk glücklich :-/
Danke, -MN
wer den ActionDetector - wozu auch immer - manuell finden will, kann ein
list TYPE=CUL_HMausführen und den ActionDetector dort anklicken.
Es existieren derzeit zwei Probleme, die ich auch in meinen Installationen nachstellen kann:
- der Aufruf von "list ActionDetector" erzeugt eine perl Warnung 2019.03.01 20:37:35 1: PERL WARNING: Use of uninitialized value in sprintf at fhem.pl line 2422.
- der ActionDetector wird nicht in dem Raum angezeigt, dem er per Attribut zugeordnet ist.
Beides unschön, aber beides hat keinen Einfluss auf die Funktion des ActionDetectors selbst.
Zu Problem Nr. 1 etwas geforscht...
Die Warnung aus der fhem.pl kommt daher, dass versucht wird, ein IODev für den ActionDetector auszugeben, das nicht existiert.
Warum da nach einem IODev gesucht wird, habe ich noch nicht rausgefunden, aber die Meldung lässt sich durch einen kleinen patch verhindern. Den muss allerdings Rudi einbauen.
Das erste habe ich auch gefunden. Werde ich korrigieren.
Das 2. Kann ich nachstellen, ist mir aber unklar
Hallo Martin, inzwischen habe ich die Lösung für 2. gefunden:
Ursache: Du darfst den ActionDetector nicht mit einem leeren subType anlegen.
Lösung: Entweder Du verwendest subType=virtual oder Du lässt das Attribut beim ActionDetector komplett weg.
Hintergrund:
in FHEMWEB wird für jedes device der Type ermittelt und im hash %FW_types() gespeichert. In diesem hash existiert für den ActionDetector kein Wert, weil das leere Attribut "subType" dafür sorgt, dass der Wert "" in den hash geschrieben wird. Und devices, die keinen Eintrag in %FW_types haben, werden im Frontend nicht angezeigt.
my $t = AttrVal($d, "subType", $defs{$d}{TYPE});
$t = AttrVal($d, "model", $t) if($t && $t eq "unknown"); # RKO: ???
$FW_types{$d} = $t;
Sofortmaßnahme für alle Leute, die ihren ActionDetector wieder sehen möchten:
{delete $attr{ActionDetector}{subType}}
in der Kommandozeile eingeben.
Das funktioniert allerdings nur bis zum nächsten FHEM Neustart, denn auch wenn man die config speichert, ist nach dem Neustart der subType wieder ohne Wert vorhanden.
Zitat von: martinp876 am 01 März 2019, 20:11:47
Ich werde HMConfig updaten damit auch der AgtionDetector eine ID bekommt.
Folgendes habe ich erfolgreich und ohne weitere Änderung an 10_CUL_HM.pm erfolgreich getestet.
Das überlebt auch einen FHEM Neustart.
Index: HMConfig.pm
===================================================================
--- HMConfig.pm (revision 18767)
+++ HMConfig.pm (working copy)
@@ -330,6 +330,7 @@
,"8002" => {name=>"PS-Th-Sens" ,st=>'THSensor' ,cyc=>'' ,rxt=>'' ,lst=>'1,4' ,chn=>"Sen:1:4",}
,"FFF0" => {name=>"CCU-FHEM" ,st=>'virtual' ,cyc=>'' ,rxt=>'' ,lst=>'' ,chn=>"Btn:1:50",}
,"FFF1" => {name=>"VIRTUAL" ,st=>'virtual' ,cyc=>'' ,rxt=>'' ,lst=>'' ,chn=>"Btn:1:50",}
+ ,"000000" => {name=>"ActionDetector",st=>'virtual',}
# "HM-LGW-O-TW-W-EU" #Funk LAN Gateway
#################open:---------------------------
Hallo Betateilchen
danke.
Die Zeile wird dann
,"0000" => {name=>"ActionDetector" ,st=>'virtual' ,cyc=>'' ,rxt=>'' ,lst=>'' ,chn=>"",
Bitte beachten, dass auch bei der Definition eines selbstbau devices ein Subtyp angegeben wird. Hier wird die Zeile von Anwender erstellt.
Guten Morgen zusammen!
Ich habe den Verdacht, ohne den Thread vollständig gelesen und verstanden zu haben, dass mein aktuelles Problem hier dazu gehört.
Ich habe eine HM-Wetterstation (HM-WDC7000) und die zugehörige Wettersensor-Kombi (HM-WDS100-C6-O).
Diese habe ich seinerzeit nach dieser Vorgehensweise eingerichtet (relevant ab Step. 3):
https://forum.fhem.de/index.php/topic,13936.msg396884.html#msg396884
Dieser, für das Sensor-Peering manuell angelegte Channel_09, wurde mir nach einem Update heute Morgen (nach 8:00 Uhr) beim FHEM-Start gelöscht (s. Logeinträge):
2019.03.02 08:53:54 3: CUL_HM_update: Wetterstation delete channel name: 373DA209
2019.03.02 08:53:54 3: Device Wetterstation added to ActionDetector with 000:10 time
Kann ich irgendetwas tun (bspw. am define des Channels), damit mir dieser erhalten bleibt?
Hier noch ein List des Channels 09:
Internals:
DEF 373DA209
FUUID 5c4a04dc-f33f-b8e7-ddda-be253b313be30e67
NAME Wetterstation_Ch09
NOTIFYDEV global
NR 538
NTFY_ORDER 50-Wetterstation_Ch09
STATE ???
TYPE CUL_HM
chanNo 09
device Wetterstation
peerList HG.XX.WS.Wetter,
.attraggr:
.attrminint:
READINGS:
2019-03-02 09:10:39 .peerListRDate 2019-03-02 09:10:39
2019-03-02 09:10:39 RegL_01. 00:00
2019-03-02 09:10:40 RegL_04.HG.XX.WS.Wetter_chn-01 00:00
2019-03-02 09:10:39 peerList HG.XX.WS.Wetter,
helper:
peerIDsRaw ,1FCD7801,00000000
regLst ,1,4p
tmplChg 0
expert:
def 1
det 1
raw 1
tpl 1
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
model HM-WDC7000
peerIDs 00000000,1FCD7801,
room hidden
Ein List des Wetterstation-Device:
nternals:
DEF 373DA2
FUUID 5c4a04dc-f33f-b8e7-3891-7a378abb48bb171c
HMUART1_MSGCNT 15
HMUART1_RAWMSG 05000023908470373DA200000000DF2B03D1
HMUART1_RSSI -35
HMUART1_TIME 2019-03-02 09:39:34
HMUART3_MSGCNT 15
HMUART3_RAWMSG 05000031908470373DA200000000DF2B03D1
HMUART3_RSSI -49
HMUART3_TIME 2019-03-02 09:39:34
IODev HMUART1
LASTInputDev HMUART1
MSGCNT 30
NAME Wetterstation
NOTIFYDEV global
NR 537
NTFY_ORDER 50-Wetterstation
STATE T: 22.3 H: 43 AP: 977
TYPE CUL_HM
channel_09 Wetterstation_Ch09
lastMsg No:90 - t:70 s:373DA2 d:000000 00DF2B03D1
protLastRcv 2019-03-02 09:39:34
protRcv 15 last_at:2019-03-02 09:39:34
protSnd 6 last_at:2019-03-02 09:10:40
protState CMDs_done
rssi_at_HMUART1 cnt:15 min:-35 max:-35 avg:-35 lst:-35
rssi_at_HMUART3 cnt:15 min:-50 max:-48 avg:-48.8 lst:-49
.attraggr:
.attrminint:
.userReadings:
HASH(0x6a21e40)
HASH(0x5dd7bd0)
Helper:
DBLOG:
airpress:
logdb:
TIME 1551515974.35839
VALUE 977
battery:
logdb:
TIME 1551515974.35839
VALUE ok
humidity:
logdb:
TIME 1551515974.35839
VALUE 43
panelPress:
logdb:
TIME 1551515974.35839
VALUE <html>↑977 hPa</html>
rssPress:
logdb:
TIME 1551515974.35839
VALUE ↑977 hPa
state:
logdb:
TIME 1551515974.35839
VALUE T: 22.3 H: 43 AP: 977
temperature:
logdb:
TIME 1551515974.35839
VALUE 22.3
READINGS:
from archivexx .D-devInfo 000A00
from archivexx .D-stc 70
2017-01-07 19:54:57 .peerListRDate 2017-01-07 19:54:57
2019-03-02 09:39:34 .protLastRcv 2019-03-02 09:39:34
2019-03-02 09:09:33 Activity alive
2016-05-06 16:21:39 CommandAccepted yes
from archivexx D-firmware 3.0
from archivexx D-serialNr MEQ0224298
2017-01-07 19:54:56 PairedTo 0x23A813
2016-05-06 15:47:21 R-pairCentral 0x23A813
2017-01-07 19:54:56 RegL_00. 02:01 0A:23 0B:A8 0C:13 00:00
2017-01-07 19:54:57 RegL_01. 00:00
2019-03-02 09:39:34 airpress 977
2019-03-02 09:39:34 battery ok
2019-03-02 09:39:34 humidity 43
2019-03-02 09:31:59 myTrend_airpress_last 977
2019-03-02 08:48:02 myTrend_airpress_trend 1
2019-03-02 09:31:59 myTrend_humidity_last 43
2019-03-02 06:21:25 myTrend_humidity_trend -1
2019-03-02 09:31:59 myTrend_temperature_last 22.4
2019-03-02 09:36:55 myTrend_temperature_trend -1
2019-03-02 09:39:34 panelPress <html>↑977 hPa</html>
2019-03-02 09:39:34 rssPress ↑977 hPa
2019-03-02 09:39:34 state T: 22.3 H: 43 AP: 977
2019-03-02 09:39:34 temperature 22.3
2019-02-10 14:51:35 trigLast HG.XX.WS.Wetter:quiet
2019-02-10 14:51:35 trig_HG.XX.WS.Wetter Quiet_120
helper:
HM_CMDNR 144
cSnd 0123A813373DA20903,0123A813373DA209041FCD780104
mId 0041
regLst ,0,1,4p
rxType 1
supp_Pair_Rep 0
tmplChg 0
ack:
expert:
def 1
det 1
raw 1
tpl 1
io:
newChn +373DA2,00,01,00
nextSend 1551515974.44448
prefIO
rxt 0
vccu ccu
p:
373DA2
00
01
00
mRssi:
mNo 90
io:
HMUART1:
-27
-27
HMUART3:
-49
-49
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_HMUART1:
avg -35
cnt 15
lst -35
max -35
min -35
at_HMUART3:
avg -48.8
cnt 15
lst -49
max -48
min -50
shadowReg:
tmpl:
Attributes:
IODev HMUART1
IOgrp ccu
actCycle 000:10
actStatus alive
autoReadReg 5_readMissing
expert 251_anything
firmware 3.0
group Wetter
model HM-WDC7000
peerIDs 00000000,
room EG->Wohnen,Uebersicht,Allgemein->Umwelt,EG.Alt->Wohnzimmer
serialNr MEQ0224298
subType THSensor
userReadings panelPress:airpress.* {'<html>'.getTrendArrowHTML(ReadingsVal($name,'myTrend_airpress_trend',0)).ReadingsVal($name,"airpress","n/v").' hPa</html>'}, rssPress:airpress.* {getTrendArrowHTML(ReadingsVal($name,'myTrend_airpress_trend',0)).ReadingsVal($name,"airpress","n/v").' hPa'}
Und der Vollständigkeit halber ein List der Wettersensoren:
Internals:
DEF 1FCD78
FUUID 5c4a04db-f33f-b8e7-e423-544358c3dfb19fed
HMUART1_MSGCNT 13
HMUART1_RAWMSG 05000040E186701FCD78000000003E56030AC0120D2030
HMUART1_RSSI -64
HMUART1_TIME 2019-03-02 09:41:09
HMUART3_MSGCNT 13
HMUART3_RAWMSG 0500003CE186701FCD78000000003E56030AC0120D2030
HMUART3_RSSI -60
HMUART3_TIME 2019-03-02 09:41:09
IODev HMUART1
LASTInputDev HMUART1
MSGCNT 26
NAME HG.XX.WS.Wetter
NOTIFYDEV global
NR 199
NTFY_ORDER 50-HG.XX.WS.Wetter
STATE T: 6.2 H: 86 B: 48 sun: 32 rl: 7.7 rc: 0.0
TYPE CUL_HM
lastMsg No:E1 - t:70 s:1FCD78 d:000000 003E56030AC0120D2030
peerList Wetterstation_chn-FF,
protLastRcv 2019-03-02 09:41:09
protRcv 13 last_at:2019-03-02 09:41:09
rssi_at_HMUART1 cnt:13 min:-67 max:-63 avg:-63.84 lst:-64
rssi_at_HMUART3 cnt:13 min:-61 max:-59 avg:-60.53 lst:-60
.attraggr:
.attreocr:
.*
.attreour:
rain
isRaining
brightness
humidity
temperature
.attrminint:
.userReadings:
HASH(0x3f4fd90)
HASH(0x4240890)
HASH(0x423b7b0)
HASH(0x4240428)
HASH(0x423ffc0)
HASH(0x423d810)
HASH(0x423c420)
HASH(0x423aba0)
Helper:
DBLOG:
absFeuchte:
logdb:
TIME 1551516069.09152
VALUE 6.3
brightness:
logdb:
TIME 1551516069.09152
VALUE 48
dewpoint:
logdb:
TIME 1551516069.09152
VALUE 4.0
humidity:
logdb:
TIME 1551516069.09152
VALUE 86
isRaining:
logdb:
TIME 1551516069.09152
VALUE 0
rain:
logdb:
TIME 1551516069.09152
VALUE 229.51
rssHum:
logdb:
TIME 1551515742.56518
VALUE ↓86%
rssTemp:
logdb:
TIME 1551516069.09152
VALUE ↑6.2°C
sunshine:
logdb:
TIME 1551516069.09152
VALUE 32
temperature:
logdb:
TIME 1551516069.09152
VALUE 6.2
windDirCorrection:
logdb:
TIME 1551516069.09152
VALUE 245
windDirCorrectionName:
logdb:
TIME 1551516069.09152
VALUE WSW
windDirRange:
logdb:
TIME 1551515486.29296
VALUE 67.5
windDirection:
logdb:
TIME 1551516069.09152
VALUE 65
windSpeed:
logdb:
TIME 1551516069.09152
VALUE 1.8
READINGS:
from archivexx .D-devInfo 3F0100
from archivexx .D-stc 70
2019-02-16 10:08:24 .peerListRDate 2019-02-16 10:08:24
2019-03-02 09:41:09 .protLastRcv 2019-03-02 09:41:09
2019-03-02 09:09:32 Activity alive
2018-11-11 10:12:30 CommandAccepted yes
from archivexx D-firmware 1.4
from archivexx D-serialNr KEQ0241742
2018-11-11 10:12:31 PairedTo 0x23A813
2018-11-11 10:12:31 R-Wetterstation_chn-FF-stormLowThresh 5
2018-11-11 10:12:31 R-Wetterstation_chn-FF-stormUpThresh 25
2015-11-14 22:01:55 R-burstRx off
2015-11-14 22:01:55 R-pairCentral 0x23A813
2015-11-14 22:01:57 R-sunThresh 30
2018-11-11 10:12:31 RegL_00. 01:00 02:01 05:00 0A:23 0B:A8 0C:13 00:00
2018-11-11 10:12:31 RegL_01. 05:1E 00:00
2018-11-11 10:12:31 RegL_01.Wetterstation_chn-FF 06:19 07:05 00:00
2019-03-02 09:41:09 absFeuchte 6.3
2017-07-31 08:35:28 battery ok
2019-03-02 09:41:09 brightness 48
2019-03-02 09:41:09 dewpoint 4.0
2019-03-02 08:51:56 hmRain 0
2019-03-02 09:41:09 humidity 86
2019-03-02 09:41:09 isRaining 0
2019-03-02 09:31:26 myTrend_humidity_last 87
2019-03-02 09:26:12 myTrend_humidity_trend -1
2019-03-02 09:31:26 myTrend_temperature_last 6.2
2019-03-02 09:26:12 myTrend_temperature_trend 1
2019-03-02 09:41:09 panelHum <html>↓86%</html>
2019-03-02 09:41:09 panelPress 1019 hPa
2019-03-02 09:41:09 panelTemp <html>↑6.2°C</html>
2019-03-02 09:41:09 panelWindSpeed 1.8 km/h (SW)
2019-03-02 09:09:32 peerList Wetterstation_chn-FF,
2018-11-11 10:06:56 powerOn 2018-11-11 10:06:56
2019-03-02 09:41:09 rain 229.51
2019-03-02 09:41:09 rain_calc_all cH: 0.0 lH: 0.0 cD: 0.0 lD: 7.7 IR: 0 Rnow: 0.0 Rdif: 0
2019-03-02 09:41:09 rain_calc_d_curr 0.0
2019-03-02 00:00:16 rain_calc_d_last 7.7
2019-03-02 00:00:16 rain_calc_d_start 229.5
2019-03-02 00:00:16 rain_calc_d_trig_tsecs 1551567600
2019-03-02 09:41:09 rain_calc_h_curr 0.0
2019-03-02 09:31:26 rain_calc_h_last 0.0
2019-03-02 09:31:26 rain_calc_h_start 229.5
2019-03-02 09:31:26 rain_calc_h_trig_tsecs 1551517200
2019-03-02 09:41:09 rain_calc_now_diff 0
2019-03-02 09:41:09 rain_calc_now_rate 0.0
2019-03-02 09:41:09 rain_calc_now_value 229.5
2019-03-02 09:41:09 rain_calc_tsecs 1551516069.07571
2018-11-11 10:06:56 recentStateType info
2019-03-02 09:41:09 rssHum ↓86%
2019-03-02 09:41:09 rssTemp ↑6.2°C
2016-05-06 16:33:11 sabotageAttackId_ErrIoId_373DA2 cnt:2
2016-05-06 16:22:53 sabotageAttackId_ErrIoId_BB0200 cnt:10
2016-05-06 16:33:11 sabotageAttack_ErrIoAttack cnt 12
2019-03-02 09:41:09 state T: 6.2 H: 86 W: 1.8 R: 229.51 IR: 0 WD: 65 WDR: 67.5 S: 32 B: 48
2019-02-10 14:51:35 storm quiet
2019-03-02 09:41:09 sunshine 32
2019-03-02 09:41:09 temperature 6.2
2018-09-23 19:29:42 trig_09 Wetterstation
2019-02-10 14:51:35 trig_3F Wetterstation
2019-02-10 14:51:35 trigger_cnt 120
2018-11-11 10:06:56 unknown 06000000
2019-03-02 09:41:09 windDirCorrection 245
2019-03-02 09:41:09 windDirCorrectionName WSW
2019-03-02 09:41:09 windDirRange 67.5
2019-03-02 09:41:09 windDirection 65
2019-03-02 09:41:09 windSpeed 1.8
helper:
HM_CMDNR 225
mId 0040
regLst ,0,1,1p
rxType 12
supp_Pair_Rep 0
tmplChg 0
expert:
def 1
det 1
raw 1
tpl 1
io:
newChn +1FCD78,00,01,00
nextSend 1551516069.22589
prefIO
rxt 0
vccu ccu
p:
1FCD78
00
01
00
mRssi:
mNo E1
io:
HMUART1:
-60
-60
HMUART3:
-60
-60
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_HMUART1:
avg -63.8461538461538
cnt 13
lst -64
max -63
min -67
at_HMUART3:
avg -60.5384615384615
cnt 13
lst -60
max -59
min -61
shadowReg:
tmpl:
Attributes:
DbLogExclude panel.*,state,rain_calc_.*,T,myTrend.*
IODev HMUART1
IOgrp ccu
actCycle 000:10
actStatus alive
alias Wettersensor
autoReadReg 5_readMissing
comment The reading hmRain is injected by notify nyReainReadings
on rain-event of hmRain_Rain
event-on-change-reading .*
event-on-update-reading rain,isRaining,brightness,humidity,temperature
expert 251_anything
firmware 1.4
group Wetter
model HM-WDS100-C6-O
peerIDs 00000000,373DA2FF,
room Uebersicht,Allgemein->Umwelt
serialNr KEQ0241742
stateFormat T: temperature H: humidity B: brightness sun: sunshine rl: rain_calc_d_last rc: rain_calc_d_curr
subType THSensor
userReadings panelTemp:temperature.* {'<html>'.getTrendArrowHTML(ReadingsVal($name,'myTrend_temperature_trend',0)).ReadingsVal($name,"temperature","n/v").'°C</html>' },
panelHum:humidity.* {'<html>'.getTrendArrowHTML(ReadingsVal($name,'myTrend_humidity_trend',0)).ReadingsVal($name,"humidity","n/v").'%</html>'},
panelPress {ReadingsVal("yaw","pressure","n/v").' hPa'},
panelWindSpeed {ReadingsVal($name,'windSpeed','n/v').' km/h ('.windDirCorrectedText(ReadingsVal($name,'windDirection','-1')).')'},
rssTemp:temperature.* {getTrendArrowHTML(ReadingsVal($name,'myTrend_temperature_trend',0)).ReadingsVal($name,"temperature","n/v").'°C' },
rssHum:humidity.* {getTrendArrowHTML(ReadingsVal($name,'myTrend_humidity_trend',0)).ReadingsVal($name,"humidity","n/v").'%'},
windDirCorrection:windDirection.* {correct180(ReadingsVal($name,'windDirection',0))},
windDirCorrectionName:windDirection.* {windDirName(correct180(ReadingsVal($name,'windDirection',0)))}
Bin für jeden Hinweis dankbar!
gb#
Vielen Dank für die Hilfe und die Lösung.
Noch eine Frage: eine HM-LC-SW4-DR (4-fach Relais Homematic Hutschiene) hat vier Kanäle.
Ein subType = switch taucht in Kanal 0 auf, nicht jedoch in den 4 Unterkanälen. Ist das gewollt und beabsichtigt?
Ich frage, weil ich einige meiner Aussenlampen mit
## Switch off all Homematic lights outdoors
set TYPE=CUL_HM:FILTER=group=Aussenbeleuchtung:FILTER=subType=switch off,
## Dim off all Homematic lights outdoors to usereading Value
set TYPE=CUL_HM:FILTER=group=Aussenbeleuchtung:FILTER=subType=dimmer pct 0,
schalte und damit die Kanäle des HM-LC-SW4-DR nicht erwische...
Danke, -MN
Ich denke, dass die Neustrukturierung der model-Zuweisung noch an anderen Stellen ein paar Probleme aufwerfen wird.
Grundsätzlich ist das ein gutes Konzept, man sollte einfach bei einer solchen grundlegenden Änderung die Geduld nicht verlieren, sondern Probleme und Fehler sachlich beschreiben. Wie man sieht, ist martin dann auch schnell dabei, eine Korrektur vorzunehmen,.
@Martin: deine Änderung an HMConfig habe ich gerade getestet, funktioniert wie gewünscht. Allerdings warst Du mit dem Einchecken heute morgen eine Minute zu spät, da war der tägliche Update-Lauf auf dem FHEM Server bereits durch. Die Änderung wird also erst morgen per update ausgeliefert.
@Benni: hast Du mal in der HMConfig.pm geschaut, ob die Geräte dort beide drinstehen?
@Morgennebel: subTypes in einzelnen Channels machen ohnehin wenig Sinn, deshalb finde ich es konsequent, künftig die subTypes nur noch im device zuzulassen. Eventuell kannst Du Deine Aufgabenstellung über ein userAttr lösen, aber die bessere Lösung wäre, einen anderen Filter für die Auswahl der Geräte zu finden. Bei mir wird z.B. über ein einheitliches Namenschema gefiltert.
Zitat von: betateilchen am 02 März 2019, 10:15:32
@Morgennebel: subTypes in einzelnen Channels machen ohnehin wenig Sinn, deshalb finde ich es konsequent, künftig die subTypes nur noch im device zuzulassen. Eventuell kannst Du Deine Aufgabenstellung über ein userAttr lösen, aber die bessere Lösung wäre, einen anderen Filter für die Auswahl der Geräte zu finden. Bei mir wird z.B. über ein einheitliches Namenschema gefiltert.
Ich stimme Dir bei Aktoren mit nur einem Kanal zu, das läßt sich leicht lösen. Bei den 4-fach Aktoren haben die einzelnen Kanäle jedoch evtl. verschiedene Aufgaben (Innen, Aussen, Licht, Heizung). Dann müsste ich die Kanäle recht unabhängig von dem Device benennen - vielleicht sehr verwirrend...
Aber es ist kein Problem, den Filter zu überarbeiten...
Ciao, -MN
bei mir steckt z.B. immer der Textteil _sw_ im Namen der Channels von Schaltaktoren. Danach kann man filtern, denn der Wert bei Filter ist ja nicht zwingend ein absoluter Wert, sondern kann auch eine regexp enthalten.
list TYPE=dummy,FILTER=NAME=~_sw_
Hallo und guten Morgen!
Seit der CUL_HM Version vom 28.2. funktioniert mein virtuelles Device der Rauchmelder nicht mehr. Als Status bekomme ich "unknown" zurück.
Internals:
DEF 11223301
FUUID 5c4486da-f33f-88c1-b542-4e977def6d07646f
NAME Rauchmelder_Team
NOTIFYDEV global
NR 102
NTFY_ORDER 50-Rauchmelder_Team
STATE unknown
TESTNR 1
TYPE CUL_HM
chanNo 01
device TeamDev
peerList Rauchmelder_Wohnzimmer,Rauchmelder_Flur,Rauchmelder_Schlafzimmer,
sdTeam sdLead
READINGS:
2019-01-08 16:15:08 aesCBCCounter 0000FE
2019-01-08 16:15:19 eventNo 03
2018-02-17 18:17:32 level 0
2019-03-02 10:39:29 peerList Rauchmelder_Wohnzimmer,Rauchmelder_Flur,Rauchmelder_Schlafzimmer,
2019-01-08 16:15:19 smoke_detect none
2019-03-02 10:39:24 state unknown
2019-01-08 16:15:19 teamCall from TeamDev:03
2018-02-17 18:17:32 trigger_cnt 2
helper:
fkt sdLead2
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
Attributes:
alarmDevice Actor
alarmSettings |set Rauchmelder_Team alarmOn|set Rauchmelder_Team alarmOff|0:00
alias Rauchmelder Team
devStateIcon off:general_ok :secur_alarm
group Rauchmelder
icon secur_smoke_detector
model VIRTUAL
peerIDs 5B788F01,5B79C601,5EDED401,
room CUL_HM,Flur,Schlafzimmer,Wohnung,Wohnzimmer
sortby 1
webCmd teamCall:alarmOn:alarmOff
Vor dem Update hatte das virtuelle Device ein anderes attr
Attributes:
model virtual_1
Dass im Status "unknown" steht, bedeutet nicht unbedingt, dass das device nicht funktioniert.
Aber irgendetwas scheint sich doch mit dem Update verändert zu haben.
Vor dem Update hatte ich den State "off", der aus dem State der Rauchmelder ausgelesen wurde.
Internals
STATE off
Zitat von: betateilchen am 02 März 2019, 10:15:32
@Benni: hast Du mal in der HMConfig.pm geschaut, ob die Geräte dort beide drinstehen?
Gerade mal nachgeschaut:
HMConfig.pm mit explizitem update (von gerade eben!)
Zitat
# $Id: HMConfig.pm 18284 2019-01-16 18:56:58Z martinp876 $
der Sensor findet sich unter
$ grep HM-WDS100-C6-O HMConfig.pm
,"0007" => {name=>"KS550" ,alias=>"HM-WDS100-C6-O"}
,"001F" => {name=>"KS888" ,alias=>"HM-WDS100-C6-O"}
,"002C" => {name=>"KS550TECH" ,alias=>"HM-WDS100-C6-O"}
,"0033" => {name=>"KS550LC" ,alias=>"HM-WDS100-C6-O"}
#,"0040" => {name=>"HM-WDS100-C6-O" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'c:w' ,lst=>'p,1' ,chn=>"",} #:w todo should be wakeup, does not react
,"0040" => {name=>"HM-WDS100-C6-O" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'c:w' ,lst=>'p,1,1:1p' ,chn=>"",} #:w todo should be wakeup, does not react
,"00AE" => {name=>"HM-WDS100-C6-O-2" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'c:w:f' ,lst=>'p,1,1:1p,4' ,chn=>"",}# odd: list one with and without peer on one channel
,"HM-WDS100-C6-O" =>{ burstRx =>1,sunThresh =>1,stormUpThresh =>1,stormLowThresh =>1}
,"HM-WDS100-C6-O-2" =>{ burstRx =>1,sunThresh =>1,stormUpThresh =>1,stormLowThresh =>1
Die Wetterstation unter:
$ grep HM-WDC7000 HMConfig.pm
,"0041" => {name=>"HM-WDC7000" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'' ,lst=>'1,4' ,chn=>"",}
Im svn gibt es allerdings eine aktuellere HMConfig.pm:
Zitat
# $Id: HMConfig.pm 18769 2019-03-02 06:46:34Z martinp876 $
Edit: gerade erst bewußt warhgenommen:
Zitat von: betateilchen am 02 März 2019, 10:15:32
@Martin: deine Änderung an HMConfig habe ich gerade getestet, funktioniert wie gewünscht. Allerdings warst Du mit dem Einchecken heute morgen eine Minute zu spät, da war der tägliche Update-Lauf auf dem FHEM Server bereits durch. Die Änderung wird also erst morgen per update ausgeliefert.
dort findet sich der Sensor unter:
$ grep HM-WDS100-C6-O HMConfig.pm
,"0007" => {name=>"KS550" ,alias=>"HM-WDS100-C6-O"}
,"001F" => {name=>"KS888" ,alias=>"HM-WDS100-C6-O"}
,"002C" => {name=>"KS550TECH" ,alias=>"HM-WDS100-C6-O"}
,"0033" => {name=>"KS550LC" ,alias=>"HM-WDS100-C6-O"}
#,"0040" => {name=>"HM-WDS100-C6-O" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'c:w' ,lst=>'p,1' ,chn=>"",} #:w todo should be wakeup, does not react
,"0040" => {name=>"HM-WDS100-C6-O" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'c:w' ,lst=>'p,1,1:1p' ,chn=>"",} #:w todo should be wakeup, does not react
,"00AE" => {name=>"HM-WDS100-C6-O-2" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'c:w:f' ,lst=>'p,1,1:1p,4' ,chn=>"",}# odd: list one with and without peer on one channel
,"HM-WDS100-C6-O" =>{ burstRx =>1,sunThresh =>1,stormUpThresh =>1,stormLowThresh =>1}
,"HM-WDS100-C6-O-2" =>{ burstRx =>1,sunThresh =>1,stormUpThresh =>1,stormLowThresh =>1
und die Wetterstation unter:
$ grep HM-WDC7000 HMConfig.pm
,"0041" => {name=>"HM-WDC7000" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'' ,lst=>'1,4' ,chn=>"",}
für mich auf den ersten Blick identisch!
Hallo webdandy, ist der status immer noch 'unknown', nachdem Du einen teamcall oder AlarmOn/Off gemacht hast?
Zitat von: betateilchen am 02 März 2019, 10:31:20
bei mir steckt z.B. immer der Textteil _sw_ im Namen der Channels von Schaltaktoren. Danach kann man filtern, denn der Wert bei Filter ist ja nicht zwingend ein absoluter Wert, sondern kann auch eine regexp enthalten.
Hmmm. Dank für den Tip, aber ich bin zu doof, diesen umzusetzen:
list TYPE=CUL_HM:FILTER=group=Aussenbeleuchtungliefert
HM_AUSSEN.SCHEUNE_4Switch_Sw_TuerLicht
HM_EG.DURCHGG_Aussenbeleuchtung_Sw_AussenDurchgang
HM_EG.DURCHGG_Aussenbeleuchtung_Sw_AussenWintergarten
hingegen
TYPE=CUL_HM:FILTER=group=Aussenbeleuchtung:FILTER=NAME=~_Sw_liefert nichts.
Laut Commandref kann NAME nur ein Reading oder Attribut sein - nicht jedoch der Name selbst. Wie genau machst Du das?
Danke, -MN
TYPE=CUL_HM:FILTER=group=Aussenbeleuchtung:FILTER=NAME=.*_Sw_.*
Zitat von: Benni am 02 März 2019, 11:49:11
Gerade mal nachgeschaut:
...
Im svn gibt es allerdings eine aktuellere HMConfig.pm:
...
für mich auf den ersten Blick identisch!
Die aktuelle Änderung in der HMConfig.pm bezog sich nur auf den ActionDetector, mit Deinem Wetterstations-Problem hatte das nix zu tun, deshalb gibt es dazu keine Unterschiede :)
Zitat von: Morgennebel am 02 März 2019, 14:23:30
Hmmm. Dank für den Tip, aber ich bin zu doof, diesen umzusetzen:
Zitat von: inoma am 02 März 2019, 14:58:31
TYPE=CUL_HM:FILTER=group=Aussenbeleuchtung:FILTER=NAME=.*_Sw_.*
Bin grade unterwegs, aber es könnte sein, dass man mehrere Filterangaben mit einem Komma trennen sollte, nicht mit einem Doppelpunkt.
Zitat von: Morgennebel am 02 März 2019, 14:23:30
Laut Commandref kann NAME nur ein Reading oder Attribut sein - nicht jedoch der Name selbst.
NAME (in Großbuchstaben) ist ein Internal, genau wie TYPE. Und dass TYPE funktioniert, hast Du ja bereits herausgefunden. In der devspec ist es ziemlich wurscht, woher der Wert für die Selektion kommt, Hauptsache es gibt den Wert überhaupt.
Filter werden mit : getrennt
Grüße
Zitat von: betateilchen am 02 März 2019, 15:10:41
Die aktuelle Änderung in der HMConfig.pm bezog sich nur auf den ActionDetector, mit Deinem Wetterstations-Problem hatte das nix zu tun, deshalb gibt es dazu keine Unterschiede :)
Mit meinem Problem kann ich vorerst auch locker leben. Den channel brauch(t)e ich ja nur genau einmal während der Einrichtung, um die beiden Geräte miteinander zu peeren. Das macht man ja i.d.R. nur einmal. ;)
Gut hminfo ist wahrscheinlich etwas unzufrieden, wenn ein peer plötzlich fehlt, aber auch das kann ich ja auch erst mal ignorieren.
Wie auch immer, sollte sich dennoch irgendwann eine Ursache/Lösung finden, wäre ich über einen entsprechenden Hinweis dankbar.
Danke einstweilen!
gb#
Zum WDC7000:
ich passe das HMConfig für dei Devices an. Nach XML hat es übrigens 10 kanäle: 1-8 ist ein "TH", 9 ein CS und 10 in Weather.
Damit werden die Kanäle angelegt, wenn das update durchgeführt und gebootet ist.
WDS550 modelle und WDC7000 sind identisch und werden über einen Alias abgebildet.
SD:
das Model hat sich von virtual_1 auf VIRTUAL geändert. Passt.
Mein virtueller SD Team funktioniert. Er steht auf off und ich kann einen Teamcall absetzten.
Um einen korrekten Status zu erhalten kann man bei den SDs einen statusrequest absetzen. Dann sollte der Teamlead wieder Bescheid wissen.
Klappt dies?
Hallo Martin,
ich habe bei meinen SDs und dem Teamlead auch den hier genannten Effekt.
Subtype ist jetzt VIRTUAL.
state beim Teamlead ist und bleibt unknown. Auch ein statusrequest ändert daran nichts.
Teamcall funktioniert.
Was kann ich noch an Infos liefern?
Hier mal der Teamlead und ein SD.
Internals:
.triggerUsed 1
DEF 5D000101
FUUID 5c5f2952-f33f-520c-20a7-e1fe3221e82f4290
NAME Rauchmelder_Team
NOTIFYDEV global
NR 272
NTFY_ORDER 50-Rauchmelder_Team
STATE unknown
TESTNR 2
TYPE CUL_HM
chanNo 01
device TeamDev1
peerList RmFlur,RmAZ,RmSZ,
sdTeam sdLead
.attraggr:
.attrminint:
READINGS:
2018-03-10 10:46:14 eventNo 0C
2018-03-10 10:46:14 level 1
2019-02-25 16:23:05 peerList RmFlur,RmAZ,RmSZ,
2018-03-10 10:46:00 recentAlarm TeamDev1
2018-03-10 10:46:14 smoke_detect none
2019-02-25 16:22:36 state unknown
2019-03-02 17:58:54 teamCall from TeamDev1:2
2017-08-08 17:55:19 trigger Short_1
2018-03-10 10:46:01 trigger_cnt 11
helper:
fkt sdLead1
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
Attributes:
model VIRTUAL
peerIDs 297D0601,297D0801,297DBC01,
room Haus
webCmd press short:press long
Internals:
.triggerUsed 1
DEF 297D06
FUUID 5c5f2952-f33f-520c-664e-a21c79a4427b7449
HMLAN1_MSGCNT 7
HMLAN1_RAWMSG E297D06,0000,C8084AE7,FF,FFC8,ACA010297D06200DB8060101003A
HMLAN1_RSSI -56
HMLAN1_TIME 2019-03-02 18:04:49
HMUART1_MSGCNT 6
HMUART1_RAWMSG 05000037ACA010297D06200DB8060101003A
HMUART1_RSSI -55
HMUART1_TIME 2019-03-02 18:04:49
IODev ser2netUart
LASTInputDev HMLAN1
MSGCNT 19
NAME RmFlur
NOTIFYDEV global
NR 269
NTFY_ORDER 50-RmFlur
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:AC - t:10 s:297D06 d:200DB8 060101003A
peerList Rauchmelder_Team,
protLastRcv 2019-03-02 18:04:49
protRcv 6 last_at:2019-03-02 18:04:49
protSnd 10 last_at:2019-03-02 18:04:49
protSndB 4 last_at:2019-03-02 18:04:49
protState CMDs_done
rssi_HMLAN1 cnt:1 min:-50 max:-50 avg:-50 lst:-50
rssi_at_HMLAN1 cnt:7 min:-62 max:-52 avg:-55.14 lst:-56
rssi_at_HMUART1 cnt:6 min:-55 max:-48 avg:-52.5 lst:-55
rssi_at_ser2netUart cnt:6 min:-54 max:-52 avg:-53.16 lst:-54
rssi_ser2netUart cnt:3 min:-58 max:-58 avg:-58 lst:-58
ser2netUart_MSGCNT 6
ser2netUart_RAWMSG 05010036ACA010297D06200DB8060101003A
ser2netUart_RSSI -54
ser2netUart_TIME 2019-03-02 18:04:49
.attraggr:
.attrminint:
READINGS:
2015-04-27 18:51:26 .D-devInfo 000100
2015-04-27 18:51:26 .D-stc CD
2017-09-11 13:07:56 .peerListRDate 2017-09-11 13:07:56
2019-03-02 18:04:49 .protLastRcv 2019-03-02 18:04:49
2019-02-25 16:23:05 Activity alive
2015-04-27 21:36:28 CommandAccepted yes
2015-04-27 18:51:26 D-firmware 1.1
2015-04-27 18:51:26 D-serialNr LEQ0067916
2017-09-11 13:07:55 PairedTo 0x200DB8
2015-04-27 18:51:28 R-pairCentral 0x200DB8
2017-09-11 13:07:55 RegL_00. 02:01 0A:20 0B:0D 0C:B8 00:00
2019-03-02 18:04:49 battery ok
2019-03-02 18:04:49 level 1
2019-02-25 16:23:05 peerList Rauchmelder_Team,
2017-09-11 13:07:50 powerOn 2017-09-11 13:07:50
2019-03-02 18:04:49 recentStateType info
2018-07-17 20:04:09 sabotageAttack_ErrIoAttack cnt 5
2018-03-10 10:46:14 smoke_detect none
2019-03-02 18:04:49 state off
2019-03-02 17:58:54 teamCall from TeamDev1:2
2017-11-25 12:34:37 trigLast Rauchmelder_Team:1
2017-11-25 12:34:37 trig_Rauchmelder_Team 1_2
helper:
HM_CMDNR 172
cSnd 01200DB8297D06010E,01200DB8297D06010E
mId 0042
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 2
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +297D06,00,00,00
nextSend 1551546290.21185
prefIO
rxt 0
vccu VCCU
p:
297D06
00
00
00
mRssi:
mNo AC
io:
HMLAN1:
-56
-56
HMUART1:
-55
-55
ser2netUart:
-48
-48
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMUART1
flg A
ts 1551546289.69938
ack:
HASH(0x3be43c0)
AC8002200DB8297D0600
rssi:
HMLAN1:
avg -50
cnt 1
lst -50
max -50
min -50
at_HMLAN1:
avg -55.1428571428571
cnt 7
lst -56
max -52
min -62
at_HMUART1:
avg -52.5
cnt 6
lst -55
max -48
min -55
at_ser2netUart:
avg -53.1666666666667
cnt 6
lst -54
max -52
min -54
ser2netUart:
avg -58
cnt 3
lst -58
max -58
min -58
tmpl:
Attributes:
.mId 0042
IODev HMLAN1
IOgrp VCCU
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.1
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,5D000101,
room CUL_HM,Flur
serialNr LEQ0067916
subType smokeDetector
webCmd statusRequest
Ein stück Log vom Teamcall und Statusrequest.
2019-03-02_17:58:54 RmFlur teamCall: from TeamDev1:2
2019-03-02_18:00:31 RmFlur battery: ok
2019-03-02_18:00:31 RmFlur level: 1
2019-03-02_18:00:31 RmFlur off
2019-03-02_18:00:37 RmFlur battery: ok
2019-03-02_18:00:37 RmFlur level: 1
2019-03-02_18:00:37 RmFlur off
2019-03-02_18:04:49 RmFlur battery: ok
2019-03-02_18:04:49 RmFlur level: 1
2019-03-02_18:04:49 RmFlur off
Gruß Otto
Vermutlich wird dem Teamlead derzeit noch die falsche modelId zugewiesen. Da sich die Zuweisung von model und subType gerade grundlegend verändert, wird das sicher auch kurzfristig wieder gradegezogen. Ähnlich wie die Probleme beim ActionDetector gestern.
Also kein Grund zur übertriebenen Sorge :)
Hast Du schonmal probiert, dem TeamLead über das Attribut "modelForce" den Wert "HM-SEC-SD" manuell zuzuweisen?
Ach Sorge mach ich mir keine. :D
Ich lese bloß mit und schaue dann bei mir. Es gibt ja keine Fehlfunktion.
Wenn ich das in der WebUI mache, dann meldet er mir
ZitatmodelForce illegal for virtual devices
Allerdings ist mein Updatestand noch vom 25.02. ???
Gruß Otto
Zitat von: Otto123 am 02 März 2019, 19:35:39
modelForce illegal for virtual devices
sowas hab ich mir fast gedacht, schade. Aber Martin ist an dem Thema dran.
Zitat von: martinp876 am 02 März 2019, 17:32:25
Zum WDC7000:
ich passe das HMConfig für dei Devices an. Nach XML hat es übrigens 10 kanäle: 1-8 ist ein "TH", 9 ein CS und 10 in Weather.
Damit werden die Kanäle angelegt, wenn das update durchgeführt und gebootet ist.
WDS550 modelle und WDC7000 sind identisch und werden über einen Alias abgebildet.
Hallo Martin,
vielen Dank! Das ging ja schnell! 8)
Eben die aktuelle HMConfig.pm aus dem svn eingespielt und tataaa ... alle 10 _Channels da!
Internals:
DEF 373DA2
FUUID 5c4a04dc-f33f-b8e7-3891-7a378abb48bb171c
HMUART1_MSGCNT 26
HMUART1_RAWMSG 05000023858470373DA200000000E12C03CF
HMUART1_RSSI -35
HMUART1_TIME 2019-03-02 19:59:40
HMUART3_MSGCNT 26
HMUART3_RAWMSG 05000030858470373DA200000000E12C03CF
HMUART3_RSSI -48
HMUART3_TIME 2019-03-02 19:59:40
IODev HMUART1
LASTInputDev HMUART1
MSGCNT 52
NAME Wetterstation
NOTIFYDEV global
NR 537
NTFY_ORDER 50-Wetterstation
STATE T: 22.5 H: 44 AP: 975
TYPE CUL_HM
channel_01 Wetterstation_TH_01
channel_02 Wetterstation_TH_02
channel_03 Wetterstation_TH_03
channel_04 Wetterstation_TH_04
channel_05 Wetterstation_TH_05
channel_06 Wetterstation_TH_06
channel_07 Wetterstation_TH_07
channel_08 Wetterstation_TH_08
channel_09 Wetterstation_CS
channel_0A Wetterstation_WEATHER
lastMsg No:85 - t:70 s:373DA2 d:000000 00E12C03CF
protLastRcv 2019-03-02 19:59:40
protRcv 26 last_at:2019-03-02 19:59:40
protSnd 42 last_at:2019-03-02 19:50:14
protState CMDs_done
rssi_at_HMUART1 cnt:26 min:-35 max:-34 avg:-34.23 lst:-35
rssi_at_HMUART3 cnt:26 min:-51 max:-48 avg:-48.69 lst:-48
.attraggr:
.attrminint:
.userReadings:
HASH(0x707c450)
HASH(0x6428858)
Helper:
DBLOG:
airpress:
logdb:
TIME 1551553180.08412
VALUE 975
battery:
logdb:
TIME 1551553180.08412
VALUE ok
humidity:
logdb:
TIME 1551553180.08412
VALUE 44
panelPress:
logdb:
TIME 1551553180.08412
VALUE <html>↓975 hPa</html>
rssPress:
logdb:
TIME 1551553180.08412
VALUE ↓975 hPa
state:
logdb:
TIME 1551553180.08412
VALUE T: 22.5 H: 44 AP: 975
temperature:
logdb:
TIME 1551553180.08412
VALUE 22.5
READINGS:
from archivexx .D-devInfo 000A00
from archivexx .D-stc 70
2017-01-07 19:54:56 .RegL_00. 02:01 0A:23 0B:A8 0C:13 00:00
2017-01-07 19:54:57 .RegL_01. 00:00
2017-01-07 19:54:57 .peerListRDate 2017-01-07 19:54:57
2019-03-02 19:59:40 .protLastRcv 2019-03-02 19:59:40
2019-03-02 19:48:34 Activity alive
2016-05-06 16:21:39 CommandAccepted yes
from archivexx D-firmware 3.0
from archivexx D-serialNr MEQ0224298
2017-01-07 19:54:56 PairedTo 0x23A813
2016-05-06 15:47:21 R-pairCentral 0x23A813
2019-03-02 19:59:40 airpress 975
2019-03-02 19:59:40 battery ok
2019-03-02 19:59:40 humidity 44
2019-03-02 19:49:53 myTrend_airpress_last 975
2019-03-02 19:46:51 myTrend_airpress_trend -1
2019-03-02 19:49:53 myTrend_humidity_last 44
2019-03-02 18:51:34 myTrend_humidity_trend 1
2019-03-02 19:49:53 myTrend_temperature_last 22.5
2019-03-02 19:36:32 myTrend_temperature_trend 1
2019-03-02 19:59:40 panelPress <html>↓975 hPa</html>
2019-03-02 19:59:40 rssPress ↓975 hPa
2019-03-02 19:59:40 state T: 22.5 H: 44 AP: 975
2019-03-02 19:59:40 temperature 22.5
2019-02-10 14:51:35 trigLast HG.XX.WS.Wetter:quiet
2019-02-10 14:51:35 trig_HG.XX.WS.Wetter Quiet_120
helper:
HM_CMDNR 133
cSnd 0123A813373DA20A040000000001,0123A813373DA20A03
mId 000B
peerFriend
peerOpt -:THSensor
regLst 0
rxType 1
supp_Pair_Rep 0
tmplChg 0
ack:
expert:
def 1
det 0
raw 0
tpl 0
io:
newChn +373DA2,00,01,00
nextSend 1551553180.24152
prefIO
rxt 0
vccu ccu
p:
373DA2
00
01
00
mRssi:
mNo 85
io:
HMUART1:
-27
-27
HMUART3:
-48
-48
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rssi:
at_HMUART1:
avg -34.2307692307692
cnt 26
lst -35
max -34
min -35
at_HMUART3:
avg -48.6923076923077
cnt 26
lst -48
max -48
min -51
shadowReg:
tmpl:
Attributes:
.mId 0041
IODev HMUART1
IOgrp ccu
actCycle 000:10
actStatus alive
autoReadReg 5_readMissing
expert 0_defReg
firmware 3.0
group Wetter
model HM-WDC7000
room EG->Wohnen,Uebersicht,Allgemein->Umwelt,EG.Alt->Wohnzimmer
serialNr MEQ0224298
subType THSensor
userReadings panelPress:airpress.* {'<html>'.getTrendArrowHTML(ReadingsVal($name,'myTrend_airpress_trend',0)).ReadingsVal($name,"airpress","n/v").' hPa</html>'}, rssPress:airpress.* {getTrendArrowHTML(ReadingsVal($name,'myTrend_airpress_trend',0)).ReadingsVal($name,"airpress","n/v").' hPa'}
webCmd getConfig:clear msgEvents
gb#
Zitat von: Otto123 am 02 März 2019, 19:35:39
Allerdings ist mein Updatestand noch vom 25.02. ???
Dann mach doch mal ein Update, am besten aus dem SVN. Es gab zwischen 25.02. und heute einige grundlegende Änderungen in CUL_HM.
Zitat von: curt am 01 März 2019, 19:08:18
Ich will nochmals erwähnen, dass sich meine drei Rauchmelder noch nicht wieder von der letzten Aktion erholten.
Zitat von: martinp876 am 01 März 2019, 20:11:47
Zu den Rauchmeldern kann ich so nichts sagen, ausser dass du in #201 ein armes würstchen bist und nie Fehler machst. Den Code hast du sicher schon - und sicher auch schon fehlerfrei implementiert. Leider habe ich nicht gefunden, was deine RMs nun nicht korrekt machen. Somit kann ich keine Aussage treffen.
Ich kann mich nicht erinnern gesagt zu haben, dass ich keine Fehler mache. Im Gegenteil, ich bin hier, weil ich nicht alles kann. Vielleicht sollten wir uns auf Folgendes einigen: Da ich Dir keine Vorwürfe mache, lässt Du solche Sätze weg. Danke.
Nachdem Dein großes Update schief ging, hatte ich große Probleme; wir sprachen in mehreren Threads darüber. Das meiste konnte ich dank Hilfe lösen. Lediglich die drei Rauchmelder sowie neuerdings diese Rauchmeldergruppe laufen neben dem Gleis.
Bei den drei Rauchmeldern steht an Stelle des model immer noch HASH. Zudem stehen die auf "RESPONSE TIMEOUT:RegisterRead". getConfig und kurzes Drücken der Taste löste das Problem nicht. Muss ich da länger drücken? (Ich habe Angst, dass damit Vollalarm ausgelöst wird.)
Hier werkelt seitdem
# $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $teamdev
Internals:
DEF 111111
FUUID 5c47b0cf-f33f-769b-01ce-4246d252b5b7b21b
IODev myHmUART
NAME TeamDev
NOTIFYDEV global
NR 861
NTFY_ORDER 50-TeamDev
STATE ???
TYPE CUL_HM
channel_01 Rauchmelder_Team
READINGS:
helper:
HM_CMDNR 126
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev myHmUART
expert 2_raw
model virtual_1
room 13 Rauch
subType virtual
webCmd virtual
Die drei Rauchmelder:
Internals:
DEF 5A5754
FUUID 5c47b0cf-f33f-769b-0110-e6b955f9a556ad50
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 3
NAME HM_5A5754
NOTIFYDEV global
NR 865
NTFY_ORDER 50-HM_5A5754
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:D6 - t:10 s:5A5754 d:FF1312 06010000
myHmUART_MSGCNT 3
myHmUART_RAWMSG 0501002AD6A6105A5754FF131206010000
myHmUART_RSSI -42
myHmUART_TIME 2019-03-02 10:47:42
peerList Rauchmelder_Team,
protLastRcv 2019-03-02 10:47:42
protRcv 3 last_at:2019-03-02 10:47:42
protSnd 3 last_at:2019-03-02 10:47:42
protState CMDs_done
rssi_at_myHmUART cnt:3 min:-42 max:-42 avg:-42 lst:-42
READINGS:
2019-02-27 22:56:28 Activity alive
from archivexx D-firmware 1.0
from archivexx D-serialNr OEQ0600470
2019-02-18 23:00:58 RegL_00.
2019-02-27 22:56:28 peerList Rauchmelder_Team,
2019-03-02 10:47:42 recentStateType info
2019-02-18 22:41:03 state RESPONSE TIMEOUT:RegisterRead
helper:
HM_CMDNR 214
mId
supp_Pair_Rep 0
tmplChg 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5A5754,00,00,00
nextSend 1551520062.79814
prefIO
rxt 0
vccu VCCU
p:
5A5754
00
00
00
mRssi:
mNo D6
io:
myHmUART:
-34
-34
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1551520062.50349
ack:
HASH(0x2d0c4c0)
D68002FF13125A575400
rssi:
at_myHmUART:
avg -42
cnt 3
lst -42
max -42
min -42
shadowReg:
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU
actCycle 099:00
actStatus alive
alias Rauch 1 Spitzboden
autoReadReg 4_reqStatus
battery_change 2018-07-19
expert 2_raw
firmware 1.0
model HASH(0x48b14f8)
msgRepeat 1
peerIDs 00000000,11111101,
readingsSupervision 86400,,Activity
room 13 Rauch
serialNr OEQ0600470
subType 1
webCmd statusRequest
Internals:
DEF 5A6710
FUUID 5c47b0cf-f33f-769b-02ab-7d8b654a83629a04
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 8
NAME HM_5A6710
NOTIFYDEV global
NR 872
NTFY_ORDER 50-HM_5A6710
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:CC - t:10 s:5A6710 d:FF1312 06010000
myHmUART_MSGCNT 8
myHmUART_RAWMSG 0501002BCCA6105A6710FF131206010000
myHmUART_RSSI -43
myHmUART_TIME 2019-03-02 05:50:15
peerList Rauchmelder_Team,
protCmdDel 4
protLastRcv 2019-03-02 05:50:15
protRcv 8 last_at:2019-03-02 05:50:15
protResnd 4 last_at:2019-03-01 17:45:28
protResndFail 4 last_at:2019-03-01 17:45:32
protSnd 12 last_at:2019-03-02 05:50:15
protState CMDs_done
rssi_at_myHmUART cnt:8 min:-53 max:-43 avg:-49 lst:-43
READINGS:
2019-03-01 17:45:51 Activity alive
2019-03-02 19:36:21 RegL_00.
2019-03-02 05:50:15 recentStateType info
2019-03-01 17:45:32 state RESPONSE TIMEOUT:RegisterRead
helper:
HM_CMDNR 204
cSnd 01FF13125A671000040000000000,01FF13125A671000040000000000
mId
supp_Pair_Rep 0
tmplChg 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5A6710,00,00,00
nextSend 1551502215.97692
prefIO
rxt 0
vccu VCCU
p:
5A6710
00
00
00
mRssi:
mNo CC
io:
myHmUART:
-35
-35
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1551502215.68236
ack:
HASH(0x470cde0)
CC8002FF13125A671000
rssi:
at_myHmUART:
avg -49
cnt 8
lst -43
max -43
min -53
shadowReg:
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU
actCycle 099:00
actStatus alive
alias No2
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HASH(0x48b14f8)
msgRepeat 1
peerIDs 00000000,11111101,
readingsSupervision 86400,,Activity
room 13 Rauch
serialNr OEQ0600403
subType 1
webCmd statusRequest
Internals:
DEF 5A6737
FUUID 5c47b0cf-f33f-769b-3db4-2e0fe3835e4e4ffb
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 4
NAME HM_5A6737
NOTIFYDEV global
NR 876
NTFY_ORDER 50-HM_5A6737
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:EA - t:10 s:5A6737 d:FF1312 06010000
myHmUART_MSGCNT 4
myHmUART_RAWMSG 0501002DEAA6105A6737FF131206010000
myHmUART_RSSI -45
myHmUART_TIME 2019-03-02 08:02:40
peerList Rauchmelder_Team,
protCmdDel 1
protLastRcv 2019-03-02 08:02:40
protRcv 4 last_at:2019-03-02 08:02:40
protResnd 1 last_at:2019-03-01 17:44:03
protResndFail 1 last_at:2019-03-01 17:44:08
protSnd 5 last_at:2019-03-02 08:02:40
protState CMDs_done
rssi_at_myHmUART cnt:4 min:-51 max:-44 avg:-46.25 lst:-45
READINGS:
2019-02-27 22:56:28 Activity alive
from archivexx D-firmware 1.0
from archivexx D-serialNr OEQ0600363
2019-03-02 19:36:21 RegL_00.
2019-02-27 22:56:28 peerList Rauchmelder_Team,
2019-03-02 08:02:40 recentStateType info
2019-03-01 17:44:08 state RESPONSE TIMEOUT:RegisterRead
helper:
HM_CMDNR 234
cSnd ,01FF13125A673700040000000000
mId
supp_Pair_Rep 0
tmplChg 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5A6737,00,00,00
nextSend 1551510160.40566
prefIO
rxt 0
vccu VCCU
p:
5A6737
00
00
00
mRssi:
mNo EA
io:
myHmUART:
-37
-37
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1551510160.11031
ack:
HASH(0x470e498)
EA8002FF13125A673700
rssi:
at_myHmUART:
avg -46.25
cnt 4
lst -45
max -44
min -51
shadowReg:
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU
actCycle 099:00
actStatus alive
alias No3
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HASH(0x48b14f8)
msgRepeat 1
peerIDs 00000000,11111101,
readingsSupervision 86400,,Activity
room 13 Rauch
serialNr OEQ0600363
subType 1
webCmd statusRequest
Zitat von: betateilchen am 02 März 2019, 20:12:38
Dann mach doch mal ein Update, am besten aus dem SVN. Es gab zwischen 25.02. und heute einige grundlegende Änderungen in CUL_HM.
Ich habe jetzt nur die 10_CUL_HM direkt aus dem SVN aktualisiert. Das hat am Zustand/Verhalten des SD und des Teamlead nichts geändert.
Hätte ich außerdem noch andere Dateien aktualisieren sollen? Ich wollte es erstmal nur "minimal invasiv" machen ;)
Gruß Otto
@Otto: eine aktuelle HMConfig.pm ist mindestens genau so wichtig wie die 10_CUL_HM.pm
@curt: solange Du kein Update auf die aktuellen Modulversionen machst und dann schaust, wie sich Deine Rauchmelder verhalten, macht eine weitere Diskussion keinen Sinn. Für eine 2 Monate alte Modulversion wirst Du keinen Support mehr erhalten.
Zitat von: betateilchen am 02 März 2019, 21:18:19
@curt: solange Du kein Update auf die aktuellen Modulversionen machst und dann schaust, wie sich Deine Rauchmelder verhalten, macht eine weitere Diskussion keinen Sinn. Für eine 2 Monate alte Modulversion wirst Du keinen Support mehr erhalten.
Diese Version hatte ich auf allgemeine Empfehlung zurückgespielt. - Ich mache regelmäßig updates, eine neuere Version kam bei mir nicht an. Ja, Zugriffsrechte richtig gesetzt. Ja, keine Update-Ausschlüsse in fhem.cfg.
Wir müssen uns mal darauf verständigen, wie ein ganz normaler Nutzer sich zu verhalten hat: Ich habe genau das getan, was mir hier gesagt wurde. Und ich würde es prima finden, wenn vor weiteren offenbar gewagten Updates bei mir zunächst einmal alles wieder normal läuft.
@curt
Ich würde an deiner Stelle das attr Model und attr subType auf dir richtigen Werte von Hand stellen.
Ich weiß nichtmal welchen Rauchmelder de hast, gibt ja mehrere Versionen.
da du mit dem Problem hier ganz alleine bist...
Zitat von: curt am 02 März 2019, 21:36:34
Ich mache regelmäßig updates, eine neuere Version kam bei mir nicht an. Ja, Zugriffsrechte richtig gesetzt. Ja, keine Update-Ausschlüsse in fhem.cfg.
Die Datei 10_CUL_HM.pm wurde zwischenzeitlich am 28.02. aktualisiert und es wird morgen früh ab 8 Uhr ein erneutes Update ausgeliefert.
Die Datei HMConfig.pm wurde zwischenzeitlich auch mehrfach aktualisiert und es wird davon ebenfalls morgen ein Update ausgeliefert.
Mein Vorschlag: installiere die morgen kommenden updates und prüfe dann, welche Probleme mit Deinen Rauchmeldern danach tatsächlich noch bestehen.
Zitat von: curt am 02 März 2019, 21:36:34
Wir müssen uns mal darauf verständigen, wie ein ganz normaler Nutzer sich zu verhalten hat: Ich habe genau das getan, was mir hier gesagt wurde. Und ich würde es prima finden, wenn vor weiteren offenbar gewagten Updates bei mir zunächst einmal alles wieder normal läuft.
Wir müssen uns mal darauf verständigen, dass FHEM kein kommerzielles Produkt ist, an das man sicherlich andere Ansprüche stellen könnte, als hier, wo alle beteiligten Entwickler den "Job" freiwillig und komplett in ihrer Freizeit bewältigen. Solche Probleme können immer auftreten, insbesondere, wenn wie jetzt ein grundlegender Umbau in einer bestehenden Modulkomponente durchgeführt wird.
Zitat von: curt am 02 März 2019, 21:36:34
Und ich würde es prima finden, wenn vor weiteren offenbar gewagten Updates bei mir zunächst einmal alles wieder normal läuft.
Dieser "Blick zurück" ist der falsche Weg.
Und ich würde es prima finden, wenn sich ein "normaler Nutzer" darüber ein paar Gedanken machen würde, dass er das alles geschenkt bekommt. Alle Entwickler hier im Forum tun ihr bestmöglichstes, sämtliche auftretenden Probleme so schnell wie möglcih zu beseitigen.
Da ist der Wunsch an die Nutzer, mit qualifizierten Fehlermeldungen anstatt mit Vorwürfen zu helfen, sicherlich das Mindeste, das man als Entwickler erwarten darf.
Zitat von: betateilchen am 02 März 2019, 21:18:19
@Otto: eine aktuelle HMConfig.pm ist mindestens genau so wichtig wie die 10_CUL_HM.pm
Danke. :) Hab ich jetzt gemacht, ändert aber auch nichts. Aber alles läuft. ;)
Zitat von: fhem-hm-knecht am 02 März 2019, 21:56:56
Ich würde an deiner Stelle das attr Model und attr subType auf dir richtigen Werte von Hand stellen.
*grmpf* Du weisst aber schon, dass sich in aktuellen Modulversionen die Attribute model und subType nicht mehr von Hand setzen lassen?
Zitat von: fhem-hm-knecht am 02 März 2019, 21:56:56
da du mit dem Problem hier ganz alleine bist...
Er ist mit dem Problem nicht alleine.
Ich kann set update auf
$Id: 10_CUL_HM.pm 18770 2019-03-02 10:03:42Z martinp876 $
keinen channel meines 4-kanal hutschienenmodels mehr schalten. bei set... fehlt z.b. on/off
alleiniges zurückspielen von
# $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $
behebt das problem und ich kann die kanäle schalten.
Internals:
CFGFN ./myfhem/dev/dev_quadswitch.cfg
DEF 267084
FUUID 5c4c1ad8-f33f-35e2-c7e3-3022dc98e4a263df
HMLAN1_MSGCNT 11
HMLAN1_RAWMSG R40209368,0001,0A46DDC1,FF,FFB6,58800226708426EDF4010400004B
HMLAN1_RSSI -74
HMLAN1_TIME 2019-03-02 21:37:50
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 11
NAME QuadSw
NOTIFYDEV global
NR 647
NTFY_ORDER 50-QuadSw
STATE CMDs_done
TYPE CUL_HM
channel_01 Zirkulationspumpe
channel_02 Raumthermostat_Vcc
channel_03 Heizung_Vcc
channel_04 Licht4DoorBell
lastMsg No:58 - t:02 s:267084 d:26EDF4 010400004B
protLastRcv 2019-03-02 21:37:50
protRcv 7 last_at:2019-03-02 21:37:50
protSnd 12 last_at:2019-03-02 21:37:50
protState CMDs_done
rssi_HMLAN1 cnt:7 min:-79 max:-74 avg:-75.42 lst:-75
rssi_at_HMLAN1 cnt:11 min:-75 max:-74 avg:-74.18 lst:-74
READINGS:
2019-01-04 04:26:22 D-firmware 1.12
2019-01-04 04:26:22 D-serialNr KEQ1102596
2019-01-08 20:36:15 powerOn 2019-01-08 20:36:15
2019-01-08 20:36:50 recentStateType info
2019-03-02 21:37:50 state CMDs_done
helper:
HM_CMDNR 88
cSnd 1126EDF42670840204C80000,1126EDF42670840204000000
mId
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +267084,00,00,00
nextSend 1551559070.47123
prefIO
rxt 0
vccu
p:
267084
00
00
00
mRssi:
mNo 58
io:
HMLAN1:
-72
-72
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rssi:
HMLAN1:
avg -75.4285714285714
cnt 7
lst -75
max -74
min -79
at_HMLAN1:
avg -74.1818181818182
cnt 11
lst -74
max -74
min -75
Attributes:
IODev HMLAN1
alias Schaltschrank
autoReadReg 4_reqStatus
expert 2_full
firmware 1.12
model HM-LC-SW4-DRr
serialNr KEQ1102596
subType switch
webCmd getConfig:clear msgEvents
Gesendet von meinem SM-J510FN mit Tapatalk
Zitat von: betateilchen am 02 März 2019, 22:06:18
Mein Vorschlag: installiere die morgen kommenden updates und prüfe dann, welche Probleme mit Deinen Rauchmeldern danach tatsächlich noch bestehen.
Ok, verstanden.
Zitat von: betateilchen am 02 März 2019, 22:06:18
Wir müssen uns mal darauf verständigen, dass FHEM kein kommerzielles Produkt ist, an das man sicherlich andere Ansprüche stellen könnte, als hier, wo alle beteiligten Entwickler den "Job" freiwillig und komplett in ihrer Freizeit bewältigen. Solche Probleme können immer auftreten, insbesondere, wenn wie jetzt ein grundlegender Umbau in einer bestehenden Modulkomponente durchgeführt wird.
Darauf müssen wir uns nicht erst verständigen; das ist wohlbekannt. Ich bin auch sehr dankbar, vermutlich sind das die meisten. Allerdings muss man nicht jeden Beitrag mit einem Kniefall und einer Entschuldigung an die Entwickler einleiten.
Zitat von: betateilchen am 02 März 2019, 22:06:18
Dieser "Blick zurück" ist der falsche Weg.
Sofern damit gemeint ist, dass ich diese alte Version nutze - genau das war die Empfehlung.
Zitat von: betateilchen am 02 März 2019, 22:06:18
Da ist der Wunsch an die Nutzer, mit qualifizierten Fehlermeldungen anstatt mit Vorwürfen zu helfen, sicherlich das Mindeste, das man als Entwickler erwarten darf.
So - es reicht jetzt. Ich kann mich nicht erinnern, einen Entwickler angegangen zu sein. Ich mühe mich, sachlich und zurückhaltend zu formulieren. Manchmal kann ich nicht sofort die richtigen Daten mitteilen; ich weiß dann schlicht nicht, was ich mitteilen muss. - Im Gegenteil ist es so, dass der eine oder andere Entwickler bei Nachfragen oder Fehlermeldungen schon ausfällig wurde. Ich meine mich auch daran erinnern zu können, dass Du mir schon mal unsachlich über den Mund gefahren bist. Ich empfehle dringend, dass jeder zunächst vor der eigenen Tür kehrt.
Danke.
@fhem-hm-knecht
Zitat von: fhem-hm-knecht am 02 März 2019, 21:56:56
Ich weiß nichtmal welchen Rauchmelder de hast, gibt ja mehrere Versionen.
HM-Sec-SD-2
Zitat von: fhem-hm-knecht am 02 März 2019, 21:56:56
Ich würde an deiner Stelle das attr Model und attr subType auf dir richtigen Werte von Hand stellen.
Falls das möglich ist (das wurde inzwischen ja bestritten) würde ich das gern tun. Was genau muss ich machen?
@curt
attr model
HM-SEC-SD
oder der neue mit 10 JahresBatterie
HM-SEC-SD-2
attr subType
smokeDetector
entweder in der fhem.cfg oder live per --> Raw definition ;)
@fhem-hm-knecht
Danke für die Erläuterung, ich habe sie problemlos abgearbeitet.
im STATE steht noch immer "RESPONSE TIMEOUT:RegisterRead", obwohl das Reading
Activity alive 2019-03-02 23:23:03
sagt.
Ich habe aber so verstanden, dass ich morgen nach einer Vollsicherung von /opt/fhem ein Update fahre und dann schaue, wie der Stand der Dinge ist.
Leider weiß ich nicht, ob TeamDev auch noch einen Schlag weg hat:
Internals:
DEF 111111
FUUID 5c47b0cf-f33f-769b-01ce-4246d252b5b7b21b
IODev myHmUART
NAME TeamDev
NOTIFYDEV global
NR 861
NTFY_ORDER 50-TeamDev
STATE ???
TYPE CUL_HM
channel_01 Rauchmelder_Team
READINGS:
helper:
HM_CMDNR 126
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev myHmUART
expert 2_raw
model virtual_1
room 13 Rauch
subType virtual
webCmd virtual
Ich habe doch keine Rauchmelder, daher kann ich dir auch nicht sagen, wie sich die Teile verhalten.
wenn deine Model und subType jetzt richtig stehen
model HASH(0x48b14f8)
und subType 1
ist devinitiv falsch!
du kannst auch mal
attr global showInternalValues 1
dann siehst du auch versteckte sachen der Modul Autoren , ist aber ein uralter Hut
Zitat von: fhem-hm-knecht am 02 März 2019, 23:56:50
Ich habe doch keine Rauchmelder, daher kann ich dir auch nicht sagen, wie sich die Teile verhalten.
Vielleicht kann jemand anders mal schauen.
Und nach dem morgigen Update (ich warte mal lieber noch einen Tag und schaue, ob andere Probleme haben) bin auch ich schlauer.
Zitat von: fhem-hm-knecht am 02 März 2019, 23:56:50wenn deine Model und subType jetzt richtig stehen
model HASH(0x48b14f8)
und subType 1
ist devinitiv falsch!
Dank Deiner Hilfe korrigiert. Das lies sich problemlos eintragen/ändern.
Zitat von: fhem-hm-knecht am 02 März 2019, 23:56:50
du kannst auch mal
attr global showInternalValues 1
dann siehst du auch versteckte sachen der Modul Autoren , ist aber ein uralter Hut
Ich trage das nachher ein. Welchen Erkenntnisgewinn habe ich dadurch? Hast Du mal bitte ein Beispiel?
ZitatDanke für die Erläuterung, ich habe sie problemlos abgearbeitet.
Mit soetwas tue ich mich sehr schwer, weil wie hast du es jetzt gemacht , hatte ja zwei Möglichkeiten geschrieben!
na und
attr global showInternalValues 1steht in der cmdref drin und b: etwas selber forschen
so als Tipp, alles was einen Punkt davor hat wurde versteckt ;D
Zitat von: fhem-hm-knecht am 03 März 2019, 00:28:58
Mit soetwas tue ich mich sehr schwer, weil wie hast du es jetzt gemacht , hatte ja zwei Möglichkeiten geschrieben!
Webinterface. 1. Rauchmelder aufgerufen.
* Klick auf das Attribut "model".
* in attr-Zeile erscheint das, dazu ein ausklappbares Modell-Menü.
* Dort "HM-SEC-SC-2" ausgewählt.
* Klick auf "attr".
* Klick auf das Attribut "subType".
* in attr-Zeile erscheint das, dazu ein ausklappbares Modell-Menü.
* Dort "smokeDetector" ausgewählt.
* Klick auf "attr".
Das Ganze für alle drei Rauchmelder. Und save natürlich.
Und nun sehen model und subType bei allen drei Rauchmeldern schön aus. Danke nochmals!
Zitat von: fhem-hm-knecht am 03 März 2019, 00:28:58
attr global showInternalValues 1
steht in der cmdref drin und b: etwas selber forschen
Sei bitte nicht böse: Das sind so Antworten, die wohl nur in diesem Forum möglich sind. Jeder muss jeden Fehler nachmachen, nur dann wird man FHEM-erwachsen.
Zitat von: fhem-hm-knecht am 03 März 2019, 00:28:58
so als Tipp, alles was einen Punkt davor hat wurde versteckt ;D
Ok, verstanden.
Zitat von: knopf_piano am 02 März 2019, 22:12:33
Ich kann set update auf
$Id: 10_CUL_HM.pm 18770 2019-03-02 10:03:42Z martinp876 $
keinen channel meines 4-kanal hutschienenmodels mehr schalten. bei set... fehlt z.b. on/off
alleiniges zurückspielen von
# $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $
behebt das problem und ich kann die kanäle schalten.
Internals:
CFGFN ./myfhem/dev/dev_quadswitch.cfg
DEF 267084
FUUID 5c4c1ad8-f33f-35e2-c7e3-3022dc98e4a263df
HMLAN1_MSGCNT 11
HMLAN1_RAWMSG R40209368,0001,0A46DDC1,FF,FFB6,58800226708426EDF4010400004B
HMLAN1_RSSI -74
HMLAN1_TIME 2019-03-02 21:37:50
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 11
NAME QuadSw
NOTIFYDEV global
NR 647
NTFY_ORDER 50-QuadSw
STATE CMDs_done
TYPE CUL_HM
channel_01 Zirkulationspumpe
channel_02 Raumthermostat_Vcc
channel_03 Heizung_Vcc
channel_04 Licht4DoorBell
lastMsg No:58 - t:02 s:267084 d:26EDF4 010400004B
protLastRcv 2019-03-02 21:37:50
protRcv 7 last_at:2019-03-02 21:37:50
protSnd 12 last_at:2019-03-02 21:37:50
protState CMDs_done
rssi_HMLAN1 cnt:7 min:-79 max:-74 avg:-75.42 lst:-75
rssi_at_HMLAN1 cnt:11 min:-75 max:-74 avg:-74.18 lst:-74
READINGS:
2019-01-04 04:26:22 D-firmware 1.12
2019-01-04 04:26:22 D-serialNr KEQ1102596
2019-01-08 20:36:15 powerOn 2019-01-08 20:36:15
2019-01-08 20:36:50 recentStateType info
2019-03-02 21:37:50 state CMDs_done
helper:
HM_CMDNR 88
cSnd 1126EDF42670840204C80000,1126EDF42670840204000000
mId
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +267084,00,00,00
nextSend 1551559070.47123
prefIO
rxt 0
vccu
p:
267084
00
00
00
mRssi:
mNo 58
io:
HMLAN1:
-72
-72
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rssi:
HMLAN1:
avg -75.4285714285714
cnt 7
lst -75
max -74
min -79
at_HMLAN1:
avg -74.1818181818182
cnt 11
lst -74
max -74
min -75
Attributes:
IODev HMLAN1
alias Schaltschrank
autoReadReg 4_reqStatus
expert 2_full
firmware 1.12
model HM-LC-SW4-DRr
serialNr KEQ1102596
subType switch
webCmd getConfig:clear msgEvents
Gesendet von meinem SM-J510FN mit Tapatalk
neue zuweisung
attr <device> model HM-LC-Sw4-DR-2
jetzt gehts mit der svn trunk (update für 3.3.2018)
$Id: 10_CUL_HM.pm 18770
Gesendet von meinem SM-J510FN mit Tapatalk
noch ein bug-fix: der Teamlead (bei mir nur für SD2) hatte ein Problem (wie von euch gemeldet) mti dem Status.
Habe ich behoben. Fix ist in SVN (10_CUL_HM)
Zitat von: martinp876 am 03 März 2019, 09:51:40
noch ein bug-fix: der Teamlead (bei mir nur für SD2) hatte ein Problem (wie von euch gemeldet) mti dem Status.
Habe ich behoben. Fix ist in SVN (10_CUL_HM)
Vielen Dank! Teamlead funktioniert bei mir nun auch wieder.
dass in "model" ein HASH steht ist natürlich falsch. Mir nicht klar, wie es reingekommen ist und wann.
Model ist in der aktuellen Version nicht mehr änderbar. Wie geht das Problemlos? Noch die alte CUL_HM version?
korrigieren könnte man es durch die Hintertür.
Das Attribut .mId in fhem.cfg korrigieren (00AA für SD2) und einen reboot machen.
Alternativ: einmal config am device auslösen. Die Meldung des Device überschreibt die primären attribute
Moin,
der Status in meinem Rauchmelder stimmt wieder :)
Gruß Otto
Bei mir geht auch alles fehlerfrei! Danke!!!!
Dann kann ich den Thread ja jetzt als gefixed markieren! :-)
einzig eine Versionsinfo wäre wieder schön: War ein Fehler von mir.
ZitatNo Id found for 10_CUL_HM.pm
Gruß Otto
Das muss ein Otto-spezifisches Problem sein. Bei mir kommt die Id wie gewünscht.
10_CUL_HM.pm 18776 2019-03-03 08:48:20Z martinp876
Zitat von: Otto123 am 03 März 2019, 11:41:28
einzig eine Versionsinfo wäre wieder schön:Gruß Otto
Wie sieht denn der Inhalt deiner 10_CUL_HM.pm aus?
Bei mir Beispielausgabe mit head in der shell
$ head /opt/fhem/FHEM/10_CUL_HM.pm
##############################################
##############################################
# CUL HomeMatic handler
# $Id: 10_CUL_HM.pm 18770 2019-03-02 10:03:42Z martinp876 $
package main;
use strict;
use warnings;
use HMConfig;
(Ich bin anscheinend nicht tagesaktuell :D)
Davon abgesehen, sollten sich Module ohne gültige SVN Id gar nicht ins repository einchecken lassen, das wird vom pre-commit hook geprüft.
Moin,
komisch, ich hatte die Datei gestern 10:20 Uhr aus dem SVN geholt. In der Datei sieht der Header so aus:
##############################################
##############################################
# CUL HomeMatic handler
# $Id$
package main;
Jetzt auf meinem Testsystem update gemacht, da kommt die Info:
10_CUL_HM.pm 18776 2019-03-03 08:48:20Z martinp876
Der Unterschied beider Dateien:
diff 10_CUL_HM.pm /opt/fhem/FHEM/10_CUL_HM.pm
4c4
< # $Id$
---
> # $Id: 10_CUL_HM.pm 18776 2019-03-03 08:48:20Z martinp876 $
Hab ich mir da selbst ein Problem bereitet? Ist das die falsche download location?
https://svn.fhem.de/fhem/trunk/fhem/FHEM/
Ich sehe gerade: Id$ ist ne Variable? Die Version wird erst beim Update dahinein geschrieben?
Wie mach ich es richtig? Sorry für meine Unwissenheit ;)
Gruß Otto
Zitat von: Otto123 am 04 März 2019, 10:59:16
Ich sehe gerade: Id$ ist ne Variable? Die Version wird erst beim Update dahinein geschrieben?
Nein. $Id$ ist ein svn keyword, das beim Einchecken in das svn repository automatisch durch die Versionansgabe von SVN ersetzt wird.
http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html
Mit FHEM oder dem Update hat das nichts zu tun. Warum Du eine Version ohne Versionsangabe gefunden hast - keine Ahnung.
Ok ich glaube ich habe es verstanden. Wenn man die Datei (z.b. mit wget) von hier holt:
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/
ist die Versionsinfo mit drin.
Holt man sie von hier
https://svn.fhem.de/fhem/trunk/fhem/FHEM/
ist nur die svn:keywords property enthalten. Die wird offenbar beim "checkout" ersetzt.
Sorry für die Verwirrung.
Gruß Otto
Ich hab ein neues Problem: mein HM-ES-TX-WM mag mich nicht mehr und liefert keine Werte vom Gaszähler.
Ein list des Devices - zu sehen: gasCnt und gasCntCalc kommen von 2019-03-01 16:44 (jetzt ist 2019-03-04 14:36):
Internals:
DEF 3BD1F4
FUUID 5c581552-f33f-4ba1-6a08-5543e9fee74fedea
HM_HMLAN1_MSGCNT 516
HM_HMLAN1_RAWMSG R48ED1928,0001,915450D2,FF,FFC6,7480023BD1F41A2B3C80
HM_HMLAN1_RSSI -58
HM_HMLAN1_TIME 2019-03-04 14:38:12
HM_HMLAN2_MSGCNT 504
HM_HMLAN2_RAWMSG 050000527480023BD1F41A2B3C80
HM_HMLAN2_RSSI -82
HM_HMLAN2_TIME 2019-03-04 14:38:12
HM_HMLAN3_MSGCNT 510
HM_HMLAN3_RAWMSG 050000467480023BD1F41A2B3C80
HM_HMLAN3_RSSI -70
HM_HMLAN3_TIME 2019-03-04 14:38:12
IODev HM_HMLAN1
LASTInputDev HM_HMLAN3
MSGCNT 1530
NAME HM_EG.KELLER_GasCounter
NOTIFYDEV global
NR 135
NTFY_ORDER 50-HM_EG.KELLER_GasCounter
STATE Nack
TYPE CUL_HM
channel_01 HM_EG.KELLER_GasCounter_IEC_01
channel_02 HM_EG.KELLER_GasCounter_IEC_02
lastMsg No:74 - t:02 s:3BD1F4 d:1A2B3C 80
protCmdDel 14
protLastRcv 2019-03-04 14:38:12
protNack 4 last_at:2019-03-04 14:38:12
protRcv 519 last_at:2019-03-04 14:38:12
protResnd 2 last_at:2019-03-04 14:36:15
protSnd 10 last_at:2019-03-04 14:38:11
protState CMDs_done_Errors:1
rssi_at_HM_HMLAN1 cnt:516 min:-64 max:-55 avg:-58.21 lst:-58
rssi_at_HM_HMLAN2 cnt:504 min:-91 max:-78 avg:-80.92 lst:-82
rssi_at_HM_HMLAN3 cnt:510 min:-77 max:-68 avg:-71.3 lst:-70
Helper:
DBLOG:
state:
DBLOG:
TIME 1551706692.16621
VALUE Nack
READINGS:
2019-03-03 17:29:13 Activity alive
2019-03-04 14:38:12 CommandAccepted no
2017-11-18 09:17:48 D-firmware 1.0
2017-11-18 09:17:48 D-serialNr MEQ0381203
2018-01-18 13:46:28 PairedTo 0x1A2B3C
2017-12-29 17:36:22 R-baudrate undef lit:255
2017-12-10 12:43:44 R-mtrConstGas 0.1 m3/I
2017-12-10 12:43:44 R-mtrConstIr 100 U/kWh
2017-12-10 12:43:44 R-mtrConstLed 10000 i/kWh
2017-12-10 12:43:44 R-mtrSensIr 0 %
2017-12-10 12:43:44 R-mtrType gas
2017-12-10 12:43:43 R-pairCentral 0x1A2B3C
2017-12-10 12:43:44 R-sign off
2017-12-10 12:43:43 R-transmDevTryMax 6
2017-12-10 12:43:44 R-transmitTryMax 6
2019-03-01 16:44:34 boot off
2019-03-01 16:44:34 eState E: 19810.6 P: 3.798
2019-03-01 16:44:34 gasCnt 19810.6
2019-03-01 16:44:34 gasCntCalc 19810.6
2019-03-01 16:44:34 gasPower 3.798
2018-12-13 10:37:08 statStateDay Nack: 10:37:13 Nack_Count: 1
2018-12-12 23:59:55 statStateDayLast Nack: 24:00:00 Nack_Count: 1
2018-12-13 10:37:08 statStateHour Nack: 00:37:13 Nack_Count: 1
2018-12-13 09:59:55 statStateHourLast Nack: 01:00:00 Nack_Count: 1
2018-12-13 10:37:08 statStateMonth Nack: 12d 10:37:13 Nack_Count: 1
2018-11-30 23:59:55 statStateMonthLast Nack: 29d 23:59:59 Nack_Count: 1
2018-12-13 10:37:08 statStateYear Nack: 2538d 10:36:26 Nack_Count: 1
2012-01-01 00:00:41 statStateYearLast Nack: 00:00:43 Nack_Count: 1
2019-03-04 14:38:12 state Nack
helper:
HM_CMDNR 116
cSnd ,011A2B3C3BD1F402040000000001
mId 00DE
peerFriend
peerOpt -:powerSensor
regLst 0
rxType 12
supp_Pair_Rep 0
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn +3BD1F4,00,00,00
nextSend 1551706692.24502
rxt 2
vccu VCCU
p:
3BD1F4
00
00
00
prefIO:
HM_HMLAN1
mRssi:
mNo 74
io:
HM_HMLAN1:
-52
-52
HM_HMLAN2:
-82
-82
HM_HMLAN3:
-70
-70
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rssi:
at_HM_HMLAN1:
avg -58.2112403100775
cnt 516
lst -58
max -55
min -64
at_HM_HMLAN2:
avg -80.9246031746031
cnt 504
lst -82
max -78
min -91
at_HM_HMLAN3:
avg -71.3019607843137
cnt 510
lst -70
max -68
min -77
tmpl:
Attributes:
IODev HM_HMLAN2
IOgrp VCCU:HM_HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 1_allReg
firmware 1.0
model HM-ES-TX-WM
room R_Keller,SYS_HomeMatic
serialNr MEQ0381203
subType powerSensor
verbose 5
webCmd getConfig:clear msgEvents
Und ein Auszug aus dem fhem-Logfile:
2019.03.04 14:30:33 3: CUL_HM set HM_EG.KELLER_GasCounter getConfig
2019.03.04 14:32:29 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_pending pending:1
2019.03.04 14:32:29 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_pending pending:2
2019.03.04 14:32:29 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_pending pending:3
2019.03.04 14:32:29 3: CUL_HM set HM_EG.KELLER_GasCounter getConfig
2019.03.04 14:33:57 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_processing... pending:3
2019.03.04 14:33:57 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:33:57 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_processing... pending:3
2019.03.04 14:33:57 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_done_Errors:1
2019.03.04 14:33:57 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:33:57 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:33:58 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:33:58 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:33:58 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:34:25 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1641.
2019.03.04 14:34:25 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1642.
2019.03.04 14:34:25 1: PERL WARNING: Use of uninitialized value $val in concatenation (.) or string at fhem.pl line 1643.
2019.03.04 14:34:33 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_pending pending:1
2019.03.04 14:34:33 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_pending pending:2
2019.03.04 14:34:33 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_pending pending:3
2019.03.04 14:34:33 3: CUL_HM set HM_EG.KELLER_GasCounter getConfig
2019.03.04 14:36:11 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_processing... pending:3
2019.03.04 14:36:11 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:36:11 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:36:15 4: CUL_HM_Resend: HM_EG.KELLER_GasCounter nr 2
2019.03.04 14:36:15 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_pending pending:3
2019.03.04 14:38:11 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_processing... pending:3
2019.03.04 14:38:11 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:38:11 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:38:11 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:38:12 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:38:12 5: CUL_HM HM_EG.KELLER_GasCounter protEvent:CMDs_done_Errors:1
2019.03.04 14:38:12 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
2019.03.04 14:38:12 4: CUL_HM HM_EG.KELLER_GasCounter dupe: dont process
Es läuft
# $Id: 10_CUL_HM.pm 18776 2019-03-03 08:48:20Z martinp876 $
Das Gerät läuft noch mit Firmware 1.0 sehe ich gerade... Mein zweites läuft mit v1.2 und scheint zu funktionieren...?
Danke, -MN
Nach Update auf Gerätefirmware v1.2 läuft alles wieder...
Danke, -MN
Beim anlernen gibts übrigens noch Fehlermeldungen:
2019.03.04 15:28:21 3: CUL_HM set VCCU hmPairForSec 600
2019.03.04 15:28:36 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4471.
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1486.
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1487.
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in regexp compilation at ./FHEM/10_CUL_HM.pm line 3039.
2019.03.04 15:28:36 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.04 15:28:36 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.04 15:28:43 1: Error: >< has no TYPE, but following keys: >helper<
HM_6649B3 taucht dann auch nicht im CUL_HM-Raum auf oder in Unsorted oder in Everything...?
Ciao, -MN
Guten Morgen!
seit der gefixten Version für "virtual sd team leads" (10_CUL_HM.pm 18776) sehe ich nach einem Neustart von FHEM folgendes im Log.
2019.03.06 06:38:42 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/10_CUL_HM.pm line 4069, <$fh> line 183.
Wahrscheinlich ist es zu vernachlässigen, aber vielleicht hat ja Martin eine Idee?
Mir ist so, als wenn solch eine Meldung in diesem Thread schon mal gepostet wurde und es als Schönheitsfehler dann gefixt wurde.
Auf Wunsch kann ich gerne weitere Infos liefern, bitte sagen welche.
Grüße Fabian
Hallo,
eine ähnliche Meldung habe ich auch im log. Bin mir aber fast sicher, das die Meldung auch vor dem uodate auf Version 18776 da war.
PERL WARNING: Useless use of hash element in void context at ./FHEM/10_CUL_HM.pm line 4069, <$fh> line 691
Gruß Holger
Hey,
seit langen habe ich mal wieder ein Update meines fhem gemacht.
Jetzt gehen meine Schalter nicht mehr, die mittels ASKSIN Firmware bespielt sind. Die werden nur noch mit einem Ausrufezeichen angezeigt, wenn ich meine alte 10_CUL_HM.pm wieder einspiele gehen die Schalter wieder.
Irgendwas ist kaputt zur Verbindung zum ASKSIN.pm
Kann mir da einer weiter helfen?
MfG
Lars
Zitat von: webdandy am 06 März 2019, 06:46:15
Guten Morgen!
seit der gefixten Version für "virtual sd team leads" (10_CUL_HM.pm 18776) sehe ich nach einem Neustart von FHEM folgendes im Log.
2019.03.06 06:38:42 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/10_CUL_HM.pm line 4069, <$fh> line 183.
Wahrscheinlich ist es zu vernachlässigen, aber vielleicht hat ja Martin eine Idee?
Mir ist so, als wenn solch eine Meldung in diesem Thread schon mal gepostet wurde und es als Schönheitsfehler dann gefixt wurde.
Auf Wunsch kann ich gerne weitere Infos liefern, bitte sagen welche.
Grüße Fabian
Kann ich ebenfalls bestätigen. Die Version davor hat die Warning nicht.
VG
Thorsten
Hallo.
Habe das selbe Problem wie netlars. Hat jemand eine Lösung dafür?
LG Lazgar
Zitat von: netlars am 06 März 2019, 18:00:23
Hey,
seit langen habe ich mal wieder ein Update meines fhem gemacht.
Jetzt gehen meine Schalter nicht mehr, die mittels ASKSIN Firmware bespielt sind. Die werden nur noch mit einem Ausrufezeichen angezeigt, wenn ich meine alte 10_CUL_HM.pm wieder einspiele gehen die Schalter wieder.
Irgendwas ist kaputt zur Verbindung zum ASKSIN.pm
Kann mir da einer weiter helfen?
Wen Du Dein Problem besser beschreibst - vielleicht ja.
Welche Firmware genau ? Kannst Du mal ein List machen, wenn es noch geht.
Hey, danke für die Antwort.
Habe auch grad gesehen, da gibt es noch einen Thread aber da gibt es auch keine Lösung, und ich denke es hängt mit der hm.pm zusammen.
Mit den letzten Versionen bekomme ich keinen Status der Schalter mehr rein, es wird mir immer ein Ausrufezeichen angezeigt. Ich kann aber noch von Fhem aus ein und aus schalten.
hier das list:
Internals:
CHANGED
DEF 52F24404
FUUID 5c7d8f7f-f33f-2a09-942b-fb827a85c782617d
NAME HM_52F244_Sw_02
NOTIFYDEV global
NR 368
NTFY_ORDER 50-HM_52F244_Sw_02
STATE off
TYPE CUL_HM
chanNo 04
device Treppe_EG_OG
peerList self01,self02,
READINGS:
2019-03-08 05:06:09 CommandAccepted yes
2017-09-06 17:17:36 R-self01-lgActionType jmpToTarget
2017-09-06 17:17:36 R-self01-shActionType jmpToTarget
2017-09-06 17:17:38 R-self02-lgActionType jmpToTarget
2017-09-06 17:17:38 R-self02-shActionType jmpToTarget
2019-03-06 17:16:40 RegL_01. 00:00 82:00 83:00 84:00 85:00 86:00 87:00 88:00 89:00 8A:00 8B:00 8C:00
2019-03-06 17:16:42 RegL_03.self01 00:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:01 0B:66 0C:66 82:00 83:00 84:00 85:00 86:00 87:00 88:00 89:00 8A:01 8B:00 8C:00
2019-03-06 17:16:45 RegL_03.self02 00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:33 0C:33 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:13 8C:33
2019-03-08 05:24:10 current 0
2019-03-08 05:06:11 deviceMsg off (to CUL_1)
2019-03-08 05:06:11 level 0 %
2019-03-08 05:06:11 pct 0
2019-03-07 20:22:38 peerList self01,self02,
2019-03-08 05:06:11 recentStateType info
2019-03-08 05:06:11 state off
2019-03-08 05:06:11 timedOn off
2019-03-07 20:07:02 trigLast fhem:02
2019-03-06 20:04:16 trig_HM_52F244_Btn_01 Short_14
2019-03-07 07:18:59 trig_HM_52F244_Btn_02 Short_18
helper:
regLst ,1,3p
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
Attributes:
alexaName Treppe Erdgeschoss
alias Treppe EG - OG
event-on-change-reading .*
group Switch
model HM-LC-Sw1PBU-FM-CustomFW
peerIDs 00000000,52F24401,52F24402,
room Beleuchtung,alexa
MfG
Lars
Aha - es handelt sich also um einen umgeflaschten Schalter. Diese Info ist durchaus wichtig. Wie sieht die Installation aus ? Welche Versionen der CustomFW-Module sind installiert ? Gibt es Ausgaben im FHEM Log ?
BTW: Hast Du schon mal diese Lösung versucht ?
https://forum.fhem.de/index.php/topic,18071.msg884602.html#msg884602
erst einmal die Frage nach den Versionen.
HMConfig solle die Version
HMConfig.pm 18774 2019-03-02 16:33:53Z martinp876
haben. Da vermute ich die ersten Probleme. Diese Version steht schon länger (ok, 1 Monat) zu Verfügung. Auf den Zusammenhang wurde hingewiesen - ist natürlich schwer zu folgen.
pairen sehe ich mir weiter an
pairen habe ich getestet. Bei mir kommt dieser Fehler nicht.
die Warning aus Zeile 4069 ist ungefährlich und wird behoben
Hallo, ich versuche gerade einen neuen Rolladenaktor zu pairen. Aber leider ohne Erfolg. Das Reading R-pairCentral taucht einfach nicht auf. Meine bereits angelernten Aktoren funktionieren problemlos. Einen funktionierenden Aktor, den ich auch gelöscht habe, lässt sich auch nicht mehr pairen. Gleiches Phänomen war schon fast am Verzweifeln bevor ich den Beitrag gefunden habe.
Meine Versionen:
# CUL HomeMatic handler
# $Id: 10_CUL_HM.pm 18776 2019-03-03 08:48:20Z martinp876 $
##############################################
# $Id: HMConfig.pm 18774 2019-03-02 16:33:53Z martinp876 $
# CUL HomeMatic device configuration data
##############################################
# $Id: 00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876 $
Leider bekomme ich die Aktoren aber auch mit ersetzten alten Versionen und einer alten fhem.cfg nicht zum pairen.
Grüße
Det
Hallo Det,
ich habe gerade mal einen Fensterkontakt (die eher zickig sind) mal entpairt alle Inhalte gelöscht und wieder gepairt. Hat auf Anhieb funktioniert. Also ich denke, die neuen Versionen haben da prinzipiell kein Problem.
Gruß Otto
Bin etwas ratlos. Das hat bisher immer problemlos funktioniert und jetzt bekomme ich keine Rolladenaktoren mehr aufgenommen (pair). Die Aktoren erscheinen, aber ich kann sie nicht ansprechen aus FHEM. Ich habe die Aktoren schon mehrfach auf Werzszustand zurück gesetzt, aber weder hmPairForSec nochhmPairSerial bringen die Aktoren so in FHEM, dass sie funktionieren. Leider auch mit den alten Versionen der Module nicht.
EDIT:
Ich habe es jetzt mit den alten Modulen geschafft. Lösung war, dass ich die Aktoren noch einmal zurück gesetzt habe, dann hmPairForSec auf dem HMUART gesetzt und NICHT auf der VCCU, dann hat der Aktor gepairt. Warum das nur so funktioniert hat, ist mir schleierhaft, aber zumindest funktionieren meine Rolläden wieder.
Sorry fürs Kapern des Threads.
Grüße
Det
ich habe es mit der vccu probiert, problemlos. da ich es nicht nachstellen kann brauche ich logs.
1) wenn der Aktor schon mit einer anderen Zentrale (HMID) gepairt ist akzeptiert er weder das neue Pairen noch das Lesen (ausser beiden Devices, welche einen Bug haben.... eQ3 ist hier nicht immer sauber.
=> damit hat FHEM also nichts zu tun, muss man im Device erledigen.
2) sollte es einen Unterschied zwischen VCCU pairen und IO pairen geben möchte ich das wissen. Details sind wichtig.
a) wieviele und welche IOs hast du? Welche davon sind aktiv?
b) wurde das Device angelegt? Welches IO ist hier eingestellt?
Zitat von: papa am 08 März 2019, 07:33:29
Aha - es handelt sich also um einen umgeflaschten Schalter. Diese Info ist durchaus wichtig. Wie sieht die Installation aus ? Welche Versionen der CustomFW-Module sind installiert ? Gibt es Ausgaben im FHEM Log ?
BTW: Hast Du schon mal diese Lösung versucht ?
https://forum.fhem.de/index.php/topic,18071.msg884602.html#msg884602
Hey, ich habe jetzt mal die Datei HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm genommen, mit der scheint es offenbar erstmal mit der aktuellen HM.pm zu funktionieren, mal sehen was über die Zeit passiert, da im anderen Thread auch gemeint wurde, nach einiger Zeit geht es nicht mehr.
Ich habe die Asksin und die Datei mal im Meld verglichen, die Deklaration am Anfang ist etwas anders gemacht.
Danke erstmal.
MfG
Lars
nun, bei der Menge der User und der verstrichenen Zeit sind keine groben schnitzer mehr vorhanden.
Das File HMConfig_HM_LC_Sw1PBU_FM_CustomFW kenne ich nicht (sollte ich?).
Es gab eine Anleitung zu Selbstbau-sensoren. Meine laufen. Bei Problemen brauche ich die Details.
Habe auch haufenweise Meldungen im FHEM log und Probleme mit dem umgeflashten Schalter (genau wie netlars). Bei dem File handelt es sich um dieses hier:
https://forum.fhem.de/index.php/topic,18071.msg326473.html#msg326473
Der Wiki-Eintrag zum Mod ist hier:
https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware
Damit scheint der Unterputzschalter auch erst mal wieder den korrekten Status anzuzeigen.
Zitat von: Morgennebel am 04 März 2019, 15:32:10
Beim anlernen gibts übrigens noch Fehlermeldungen:
2019.03.04 15:28:21 3: CUL_HM set VCCU hmPairForSec 600
2019.03.04 15:28:36 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4471.
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1486.
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1487.
2019.03.04 15:28:36 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in regexp compilation at ./FHEM/10_CUL_HM.pm line 3039.
2019.03.04 15:28:36 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.04 15:28:36 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.04 15:28:43 1: Error: >< has no TYPE, but following keys: >helper<
Gab es zu dieser Fehlermeldung einen Lösungsansatz? Ich bekomme bei jedem neuen Device den gleichen Fehler:
Error: >< has no TYPE, but following keys: >helper<
Mein FHEM ist gestern das letzte mal komplett mit Update versehen worden. Bis auf diese Fehlermeldung bei neuen Device tut alles ohne Probleme.
Gruss
Enno
Hallo zusammen,
ich habe heute auch ein Update gemacht und nun folgenden Fehler beim Neustart:
2019.03.11 18:09:24 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/10_CUL_HM.pm line 4069, <$fh> line 31.
2019.03.11 18:09:24 1: stacktrace:
2019.03.11 18:09:24 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (4069)
2019.03.11 18:09:24 1: (eval) called by fhem.pl (2591)
2019.03.11 18:09:24 1: (eval) called by fhem.pl (2590)
2019.03.11 18:09:24 1: main::CommandReload called by fhem.pl (1987)
2019.03.11 18:09:24 1: main::LoadModule called by fhem.pl (2044)
2019.03.11 18:09:24 1: main::CommandDefine called by fhem.pl (1234)
2019.03.11 18:09:24 1: main::AnalyzeCommand called by fhem.pl (1080)
2019.03.11 18:09:24 1: main::AnalyzeCommandChain called by fhem.pl (1375)
2019.03.11 18:09:24 1: main::CommandInclude called by fhem.pl (1234)
2019.03.11 18:09:24 1: main::AnalyzeCommand called by fhem.pl (1080)
2019.03.11 18:09:24 1: main::AnalyzeCommandChain called by fhem.pl (1375)
2019.03.11 18:09:24 1: main::CommandInclude called by fhem.pl (597)
Grüße
Daniel
@Daniel: das ist eine Warnung. Kein Problem . Unschön. Wird behoben.
@ enno
Ich hatte schon getestet ohne es zu reproduzieren. Muss ich wohl noch einmal. Hat das anlernen funktioniert?
Zitat von: martinp876 am 14 März 2019, 14:01:24
@ enno
Ich hatte schon getestet ohne es zu reproduzieren. Muss ich wohl noch einmal. Hat das anlernen funktioniert?
Anlernen von neuen Device funktioniert. Ich bekomme die Meldung allerdings bei Protokollen, die vom Nachbarn aufgefangen werden. Sind also alles Device, die ich sowieso nicht haben will. Ich habe Autocreate deaktiviert so dass ich nur die Meldungen im Log habe. Wenn du mir sagst, wo ich mit Daten oder Logs unterstützen kann? Ich stelle Autocreate mal an und schaue was dann ein List der neuen Device sagt.
Edit:
Eben im Log:
2019.03.14 19:08:24 1: PERL WARNING: Use of uninitialized value $mId in hash element at ./FHEM/10_CUL_HM.pm line 6667.
2019.03.14 19:08:24 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 6667.
2019.03.14 19:08:24 1: PERL WARNING: Use of uninitialized value $mId in hash element at ./FHEM/10_CUL_HM.pm line 6695.
2019.03.14 19:08:35 2: CUL_HM Unknown device HM_0AA0D3 is now defined
2019.03.14 19:08:35 2: autocreate: define HM_0AA0D3 CUL_HM 0AA0D3
2019.03.14 19:08:40 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/10_CUL_HM.pm line 8716.Neues Device erscheint aber in der Oberfläche nicht wie erwartet im Raum "NEW" daher habe ich mal einen Blick (keine Sorge, ich editiere dort nicht) in fhem.cfg geworfen:
define HM_0AA0D3 CUL_HM 0AA0D3
setuuid HM_0AA0D3 5c8a98a3-f33f-7f96-8888-399728565e543360
attr HM_0AA0D3 .mId 506E
attr HM_0AA0D3 DbLogExclude .*
attr HM_0AA0D3 autoReadReg 4_reqStatus
attr HM_0AA0D3 expert 2_raw
attr HM_0AA0D3 firmware 9.11
attr HM_0AA0D3 model unknown
attr HM_0AA0D3 room NEW
attr HM_0AA0D3 serialNr �^=�����r
attr HM_0AA0D3 subType Ich deaktiviere jetzt Autocreate wieder.
Gruss
Enno
Zitat von: enno am 14 März 2019, 15:48:25
Neues Device erscheint aber in der Oberfläche nicht wie erwartet im Raum "NEW" daher habe ich mal einen Blick (keine Sorge, ich editiere dort nicht) in fhem.cfg geworfen:
Ein List geht
Internals:
CFGFN
CUL_0_MSGCNT 1
CUL_0_RAWMSG A31FB00000AA0D30A06669B506E12865E3DFAA2000000727D6000F0E99F6C684884103DCE8CF11034060122BE45248BCB0B5E::-45:CUL_0
CUL_0_RSSI -45
CUL_0_TIME 2019-03-14 19:08:35
DEF 0AA0D3
FUUID 5c8a98a3-f33f-7f96-8888-399728565e543360
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 1
NAME HM_0AA0D3
NOTIFYDEV global
NR 8703
STATE ???
TYPE CUL_HM
chanNo 01
lastMsg No:FB - t:00 s:0AA0D3 d:0A0666 9B506E12865E3DFAA2000000727D6000F0E99F6C684884103DCE8CF11034060122BE45248BCB0B5E
protLastRcv 2019-03-14 19:08:35
protRcv 1 last_at:2019-03-14 19:08:35
rssi_at_CUL_0 cnt:1 min:-45 max:-45 avg:-45 lst:-45
READINGS:
2019-03-14 19:08:35 D-firmware 9.11
2019-03-14 19:08:35 D-serialNr �^=��r
helper:
HM_CMDNR 290
mId
peerFriend -
peerOpt -
regLst
supp_Pair_Rep 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +0AA0D3,00,01,00
nextSend 1552586915.65125
prefIO
rxt 0
vccu
p:
0AA0D3
00
01
00
mRssi:
mNo FB
io:
CUL_0:
-37
-37
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL_0:
avg -45
cnt 1
lst -45
max -45
min -45
tmpl:
Attributes:
DbLogExclude .*
autoReadReg 4_reqStatus
expert 2_raw
firmware 9.11
model unknown
room NEW
serialNr �^=��r
subType
Zitat von: enno am 14 März 2019, 15:48:25
Ich deaktiviere jetzt Autocreate wieder.
und schon sieht es im Log wieder so aus:
2019.03.14 19:58:26 2: CUL_HM Unknown device HM_A8AB86 is now defined
2019.03.14 20:00:12 1: Error: >< has no TYPE, but following keys: >helper<
Ok, gute info. Es geht also nicht ums anlernen sondern um messages unbekanter devices. Ganz andere Baustelle. Hier habe ich nicht gesucht. Werde ich prüfen, hört sich lösbar an.
nur ein paar Seiten dieses langen Treads eben durchgearbeitet.... mein fhem war leider (oder zum Glück) Jan/Feb offline .... heute dann ein update durchgeführt.
Primär basiert meine komplette Automation auf HMWired
Schnell vorab: Alles (auf den ersten Blick) funktionert. Ich möchte eigentlich nur berichten, dass
PERL WARNING: Useless use of hash element in void context at ./FHEM/10_CUL_HM.pm line 4069, <$fh> line 1047.
2019.03.15 19:59:55 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/Meta.pm line 1152.
sich ins Log geschmuggelt hat. Falls weitere Infos weiterhelfen, bitte anmerken.
Dank und Grüße
das sind wirklich defekte messages.
Der update ist eingecheckt. Probier mal, ob alles gefangen ist.
sieht gut aus. Danke
Mmh, das
2019.03.16 12:33:30 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/Meta.pm line 1152.
kommt noch. Allerdings weiß ich nicht, ob es was mit CUL_HM zu tun hat.
das modul kenne ich nicht. Scheint neu, den vor meinem Update war es garnicht vorhanden. Da musst du dich an Loredo wenden. Ich habe aktuell keine Ahnung wozu es gut sein soll. Es wird bei mir auch nicht gestartet.
Danke, Martin
Hallo Martin,
ich habe eine Rauchmelder neu angelegt und es hat ohne Probleme funktioniert. Tolle Arbeit!
Eine Kleinigkeit ist mir aufgefallen. Laut WiKi sollen die Attribute IODev und IOgrp automatisch eingetragen werden.
Das war bei mir nicht der Fall. Ich habs dann händisch nachgetragen...
Hier mal ein Logauszug falls es Dir hilft!
2019.03.17 12:43:42 3: CUL_HM set VCCU hmPairForSec 60
2019.03.17 12:43:47 2: CUL_HM Unknown device HM_5EDBCB is now defined
2019.03.17 12:43:47 2: autocreate: define HM_5EDBCX CUL_HM 5EDBCX
2019.03.17 12:43:47 2: autocreate: define FileLog_HM_5EDBCB FileLog ./log/HM_5EDBCX-%Y.log HM_5EDBCX
2019.03.17 12:43:48 3: Device HM_5EDBCX added to ActionDetector with 099:00 time
2019.03.17 12:43:48 3: CUL_HM pair: HM_5EDBCB smokeDetector, model HM-SEC-SD-2 serialNr
2019.03.17 12:43:55 3: CUL_HM set HM_5EDBCX statusRequest
2019.03.17 12:43:59 3: CUL_HM set HM_5EDBCX getConfig
Kann es sein, dass auch etwas mit dem subType "remoteAndSwitch" für die Schalter mit Custom-Firmware für HM_LC_Sw1PBU_FM schief lief beim letzten update?
Bei mir taucht dieser SubType in der Dropdownauswahl nicht mehr auf und die Funktion der Schalter ist stark eingeschränkt.
Moin Moin,
ich hab gerade ein update & restart gemacht und kann immer noch nicht komplett anlernen:
2019.03.19 16:01:04 3: CUL_HM set VCCU hmPairForSec 600
2019.03.19 16:01:25 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.19 16:01:25 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4467.
2019.03.19 16:01:25 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1483.
2019.03.19 16:01:25 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1484.
2019.03.19 16:01:25 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1528.
2019.03.19 16:01:25 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.19 16:01:25 3: HM_HMLAN1: Unknown code A1AC984006649B30000002800694F45513233303636383610010100::-85:HM_HMLAN1, help me!
2019.03.19 16:01:25 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.19 16:01:25 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.19 16:01:25 3: HM_HMLAN2: Unknown code A1AC984006649B30000002800694F45513233303636383610010100::-57:HM_HMLAN2, help me!
2019.03.19 16:01:25 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.19 16:01:25 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.19 16:01:25 3: HM_HMLAN3: Unknown code A1AC984006649B30000002800694F45513233303636383610010100::-49:HM_HMLAN3, help me!
2019.03.19 16:01:27 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/66_EseraDigitalInOut.pm line 560.
2019.03.19 16:01:27 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/66_EseraAnalogInOut.pm line 336.
2019.03.19 16:01:27 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/66_EseraTemp.pm line 126.
2019.03.19 16:01:48 1: Error: >< has no TYPE, but following keys: >helper<
Es handelt sich um einen normalen UP-Aktor von Homematic.
Danke, -MN
Zitat von: Haecksler am 19 März 2019, 13:19:13
Kann es sein, dass auch etwas mit dem subType "remoteAndSwitch" für die Schalter mit Custom-Firmware für HM_LC_Sw1PBU_FM schief lief beim letzten update?
Bei mir taucht dieser SubType in der Dropdownauswahl nicht mehr auf und die Funktion der Schalter ist stark eingeschränkt.
Nachtrag: Nach einem manuellen reload von 10_CUL_HM war das Problem behoben.... Scheint also ein Timing-Problem beim Start zu sein.
Kann mir eventuell weiterhelfen? Ich bin langsam am verzweifeln :(
Seit den letzten Updates der 10_CUL_HM habe ich Probleme mit meinen HM-CC-RT_DN. Habe über die Systemevents heraus bekommen, dass während der Fhem-Initialisierung die Geräte angelegt werden, aber auch gleich wieder gelöscht werden.
Habe bereits probiert die Geräte neu zu pairen, jedoch nach Neustart selbe Spiel.
Konnte dies jetzt soweit verfolgen, dass ich das Attribut "model" und "modelForce" als Ursache lokalisieren konnte. Sobald eins von beiden Attributen gesetzt wird, ist das Gerät in Fhem glöscht.
Anmerkung: Dieses Problem besteht nur bei meinem HM-CC-RT_DN, bei meinen HM-SEC-RHS sind bisher keine Problem erkennbar.
define WZ.HKTH.001 CUL_HM 5F9A12
attr WZ.HKTH.001 IODev CUL_HM
attr WZ.HKTH.001 alias WZ.HKTH.001 - Thermostatventil
attr WZ.HKTH.001 actCycle 000:10
attr WZ.HKTH.001 actStatus alive
attr WZ.HKTH.001 autoReadReg 4_reqStatus
attr WZ.HKTH.001 burstAccess 1_auto
attr WZ.HKTH.001 expert 1_all
attr WZ.HKTH.001 icon hm-cc-rt-dn
#attr WZ.HKTH.001 model HM-CC-RT-DN
attr WZ.HKTH.001 subType thermostat
attr WZ.HKTH.001 room Geräte
attr WZ.HKTH.001 group HLK - Wohnzimmer
attr WZ.HKTH.001 sortby 1
attr WZ.HKTH.001 webCmd getConfig:sysTime:burstXmit
Internals:
CFGFN /opt/fhem/config_cfg/HM-Device_WZ.HKTH.001.cfg
DEF 5F9A12
FUUID 5c9a7e44-f33f-31dd-0d27-2851510b42511512
IODev CUL_HM
NAME WZ.HKTH.001
NOTIFYDEV global
NR 86
NTFY_ORDER 50-WZ.HKTH.001
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 WZ.HKTH.001_Weather
channel_04 WZ.HKTH.001_Clima
channel_07 WZ.HKTH.001_Control
protCondBurst unknown
READINGS:
2019-03-26 20:31:22 state RESPONSE TIMEOUT:RegisterRead
helper:
HM_CMDNR 241
mId
peerFriend -
peerOpt -
regLst
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn +5F9A12,00,00,00
prefIO
rxt 0
vccu
p:
5F9A12
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
tmpl:
Attributes:
DisplayName Wohnzimmer - Thermostatventil
DisplayRoom Wohnzimmer
IODev CUL_HM
actCycle 000:10
actStatus alive
alias WZ.HKTH.001 - Thermostatventil
autoReadReg 4_reqStatus
burstAccess 1_auto
expert 1_all
group HLK - Wohnzimmer
icon hm-cc-rt-dn
room Geräte
sortby 1
subType
userattr DisplayName DisplayRoom
webCmd getConfig:sysTime:burstXmit
Hallo,
nach längerem Zögern habe ich auch mal wieder ein Update durchgeführt.
Funktioniert alles soweit, ".mId" und "FUUID" wurden überall automatisch ergänzt, zwei Dinge sind mir aber aufgefallen:
- im Log taucht eine Warnung auf:
PERL WARNING: Use of uninitialized value in join or string at ./FHEM/10_CUL_HM.pm line 8714.
- bei meinen 2-kanaligen UP-Schaltern "HM-LC-SW2-FM" gibt es kein Reading "Activity" mehr, weder im Device noch in den Kanälen.
Die einpoligen "HM-LC-SW1-FM" haben noch eins.
Gibt es eine Trick, das wiederherzustellen?
Viele Grüße,
Nik
Tja,
und ich kann immer noch nicht meinen Wandschalter anlernen. Ich habe die Werkseinstellungen erzwungen und die VCCU im Anlernmodus.
Eventmonitor:
2019-03-28 12:10:17 Global global UNDEFINED HM_6649B3 CUL_HM 6649B3
2019-03-28 12:10:17 Global global UNDEFINED HM_6649B3 CUL_HM 6649B3
2019-03-28 12:10:17 HMLAN HM_HMLAN1 UNKNOWNCODE A1A0184006649B30000002800694F45513233303636383610010100::-75:HM_HMLAN1
2019-03-28 12:10:17 Global global UNDEFINED HM_6649B3 CUL_HM 6649B3
2019-03-28 12:10:17 Global global UNDEFINED HM_6649B3 CUL_HM 6649B3
2019-03-28 12:10:17 HMUARTLGW HM_HMLAN2 UNKNOWNCODE A1A0184006649B30000002800694F45513233303636383610010100::-68:HM_HMLAN2
2019-03-28 12:10:17 Global global UNDEFINED HM_6649B3 CUL_HM 6649B3
2019-03-28 12:10:17 Global global UNDEFINED HM_6649B3 CUL_HM 6649B3
2019-03-28 12:10:17 HMUARTLGW HM_HMLAN3 UNKNOWNCODE A1A0184006649B30000002800694F45513233303636383610010100::-50:HM_HMLAN3
Logfile:
2019.03.28 12:08:23 3: CUL_HM set VCCU hmPairForSec 600
2019.03.28 12:08:37 4: CUL_HM VCCU dupe: dont process
2019.03.28 12:08:48 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:08:48 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:08:48 3: HM_HMLAN3: Unknown code A1A1684006649B30000002800694F45513233303636383610010100::-47:HM_HMLAN3, help me!
2019.03.28 12:08:48 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:08:48 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:08:48 3: HM_HMLAN2: Unknown code A1A1684006649B30000002800694F45513233303636383610010100::-69:HM_HMLAN2, help me!
2019.03.28 12:09:01 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:01 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:01 3: HM_HMLAN1: Unknown code A1A1784006649B30000002800694F45513233303636383610010100::-72:HM_HMLAN1, help me!
2019.03.28 12:09:01 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:01 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:01 3: HM_HMLAN2: Unknown code A1A1784006649B30000002800694F45513233303636383610010100::-71:HM_HMLAN2, help me!
2019.03.28 12:09:01 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:01 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:01 3: HM_HMLAN3: Unknown code A1A1784006649B30000002800694F45513233303636383610010100::-47:HM_HMLAN3, help me!
2019.03.28 12:09:06 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:06 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:06 3: HM_HMLAN1: Unknown code A1A1884006649B30000002800694F45513233303636383610010100::-66:HM_HMLAN1, help me!
2019.03.28 12:09:06 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:06 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:06 3: HM_HMLAN2: Unknown code A1A1884006649B30000002800694F45513233303636383610010100::-68:HM_HMLAN2, help me!
2019.03.28 12:09:06 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:06 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:09:06 3: HM_HMLAN3: Unknown code A1A1884006649B30000002800694F45513233303636383610010100::-48:HM_HMLAN3, help me!
2019.03.28 12:09:08 1: Error: >< has no TYPE, but following keys: >helper<
2019.03.28 12:10:03 3: CUL_HM set VCCU hmPairForSec 600
2019.03.28 12:10:17 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:10:17 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:10:17 3: HM_HMLAN1: Unknown code A1A0184006649B30000002800694F45513233303636383610010100::-75:HM_HMLAN1, help me!
2019.03.28 12:10:17 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:10:17 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:10:17 3: HM_HMLAN2: Unknown code A1A0184006649B30000002800694F45513233303636383610010100::-68:HM_HMLAN2, help me!
2019.03.28 12:10:17 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:10:17 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.03.28 12:10:17 3: HM_HMLAN3: Unknown code A1A0184006649B30000002800694F45513233303636383610010100::-50:HM_HMLAN3, help me!
2019.03.28 12:10:27 1: Error: >< has no TYPE, but following keys: >helper<
2019.03.28 12:10:27 4: CUL_HM VCCU dupe: dont process
Vielleicht sollte ich das zum Anlaß nehmen, um auf ZWave umzusteigen...
Danke, -MN
@tm4489. Die mId ist leer. Diese wird automatisch gefüllt, einmalig aus Model. Wenn model nicht korrekt war gibt es keinen Match. Grundsätzlich geht es, alle meine wurden konvertiert. Ich vermute deine waren nicht korrekt im device.
Wenn du config auslöst sendet das device die Id und model sollte gesetzt werden. Pairen ist definitiv nicht nötig.
Ich habe das Update für 10_CUL_HM.pm noch immer excludet und lese die täglichen Meldungen mit Grausen ... obwohl ja viele den Sprung inzwischen geschafft zu haben scheinen...
Vielleicht traue ich mich heute auch noch.
Hallo Martin,
ich habe auch heute ein update gemacht. Bei mir kamen folgende Fehler:
Zitat2019.04.01 08:02:48 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1636.
2019.04.01 08:02:48 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1637.
2019.04.01 08:02:48 1: PERL WARNING: Use of uninitialized value $val in concatenation (.) or string at fhem.pl line 1638.
Hat das vielleicht etwas mit den Homematic Modulen zu tun, oder soll ich allgemein nachfragen ?
Weiterhin habe ich das Update wieder rückgängig gemacht, da einige Devices nicht korrekt fkt.. Wenn ich durch meine Recherche alles richtig verstanden habe, so muss ich bei dem Update darauf achten, dass die subtypes richtig gesetzt werden, damit dann auch die .mId richtig gesetzt werden ... richtig ??
Ich hatte nämlich Probleme einerseits mit den Devices von: Neue Firmware für HM_LC_Sw1PBU_FM, andererseits z.B. mit dem ACIONDETECTOR, der nach dem update ein leeres Attribut .mId hatte....
Ich weiss, könnten viele Baustellen sein, meine Fragen, aber diese Sachen habe ich nach dem Update festgestellt....
Vg
mcfly
Um meinem Namensvetter vorzugreifen und ihn etwas zu entlasten:
Zitat von: mcfly71 am 01 April 2019, 16:04:55
Bei mir kamen folgende Fehler:
Perl WARNINGS sind keine Fehler, das sind Warnungen und erstmal recht unkritisch. (Trotzdem sollte Martin das wissen.)
Zitat von: mcfly71 am 01 April 2019, 16:04:55
Ich hatte nämlich Probleme einerseits mit den Devices von: Neue Firmware für HM_LC_Sw1PBU_FM, andererseits z.B. mit dem ACIONDETECTOR, der nach dem update ein leeres Attribut .mId hatte....
Da müsstest Du für jede Device sehr genau (list) zeigen, wie es auszusehen hat - und wie es nach dem Update falsch aussieht. Martin kann das ja nicht raten.
Hoffe ein wenig geholfen zu haben.
Zitat von: mcfly71 am 01 April 2019, 16:04:55
Hat das vielleicht etwas mit den Homematic Modulen zu tun, oder soll ich allgemein nachfragen ?
Vielleicht erst mal mittels stacktrace (https://fhem.de/commandref_DE.html#stacktrace) versuchen herauszufinden, wo die Meldung denn nun wirklich her kommt.
gb#
Hallo zusammen,
also ok, natürlich sind warnings warnungen, aber uninitialisierte Variablen können nun doch schon sehr ungewolltes Verhalten hervorrufen.
Dann eine Frage an Martin: Die leere .mID im ACTIONDETECTOR.... ist das so gewollt ? Soll ich händisch, wenn .mID leer ist etwas einsetzen ? Und wenn ja was ?
Bzgl. des HM_LC_Sw1PBU_FM mit selbstgemachter Firmware galt halt: Alles hat bislang normal funktioniert. Nach dem Update habe ich z.B. "set DEVICENAME on" gemacht, und es war der state immer auf set_on bzw. umgekehrt alles mit off und set_off.
VG
mcfly
Uninitialusierte Variable geht nicht.
Was meinst du mit leer? 0000 oder ""?
Hallo Martin,
Zitat von: martinp876 am 04 April 2019, 21:02:39
Uninitialusierte Variable geht nicht.
Was meinst du mit leer? 0000 oder ""?
Naja.. z.B. die Meldung
Use of uninitialized value $val in substitution (s///) at fhem.pl line 1636
heisst ja normalerweise sowas wie:
$val wird irgendwo benutzt, ohne ihr vorher einen Wert zugewiesen zu haben.
Welchen Wert perl in einem solchen Fall da rein schreibt, kann Zufall sein...
Aber ich sehe soeben... du meintest bestimmt das .mID Attribute mit deiner Frage.....
Das Attribut des Actiondetectors war einfach nur da, da stand nix drin, kein 000 oder Space oder irgendwas....
VG
mcfly
Hallo Gemeinde und Martin,
ich habe mich heute mal etwas näher mit der Thematik beschäftigt. Nachdem ich heute (Sonntag 07.04.2019) ein Update gemacht habe,
funktionierte soweit erstmal alles ganz gut.
Die .mId des Actiondetectors war - im Gegensatz zu vorigem Male - nicht leer sondern 0000 -> alles ok soweit.
Probleme machen die Homematic Geräte mit veränderter Firmware. Vor dem Update war als subType 'remoteAndSwitch', schätzungsweise geholt aus dem zugeordneten *.pm File:
Zitat
sub
registerHM_LC_Sw1PBU_FM_CustomFW()
{
{$HMConfig::culHmModel{"F0A9"} = {name=>"HM-LC-Sw1PBU-FM-CustomFW",st=>'remoteAndSwitch',cyc=>'',rxt=>'',lst=>'1,3:3p.4p,4:1p.2p',chn=>"Btn:1:2,Sw:3:4"}}
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW00"}{fwUpdate} ="<filename>"};
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW01"} = $HMConfig::culHmSubTypeSets{"THSensor"}};
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW02"} = $HMConfig::culHmSubTypeSets{"THSensor"}};
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW03"} = $HMConfig::culHmSubTypeSets{"switch"}};
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW04"} = $HMConfig::culHmSubTypeSets{"switch"}};
{$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW01"} = $HMConfig::culHmRegType{remote}};
{$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW02"} = $HMConfig::culHmRegType{remote}};
{$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW03"} = $HMConfig::culHmRegType{switch}};
{$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW04"} = $HMConfig::culHmRegType{switch}};
#Log(1, "Registered F0A9");
}
#Log(1, "Loaded CustomFS");
InternalTimer(gettimeofday()+10,"registerHM_LC_Sw1PBU_FM_CustomFW","nothing", 0);
Ich habe dementsprechend nun mir selbst in der HMConfig.pm eine neue Zeile eingetragen:
Zitat
,"FF69" => {name=>"HM-LC-Sw1PBU-FM-CustomFW",st=>'remoteAndSwitch' ,cyc=>'' ,rxt=>'' ,lst=>'1,3:3p.4p,4:1p.2p' ,chn=>"Btn:1:2,Sw:3:4",}
angelehnt an dem original Device : 'HM-LC-Sw1PBU-FM'
Nun scheint alles wieder normal zu funktionieren.
@Martin: Meine Bitte, ist es möglich diese Zeile fest aufzunehmen ??? Ansonsten geht das Spiel es gibt kein subType und dementsprechend keine .mId beim nächsten Update wieder von vorne los ?!!!
Vile Grüße
mcfly
für selbstbau devices habe ich ein Interface installiert. Diese Devices komme nicht in das Standard File.
Für selbstbau Devices musst du ein eigenes File definieren
Siehe Beispiel im Anhang
Name HMConfig_<meinName>.pm
Schon so alt - ich erinnere mich kaum.:(
Hallo MArtin,
ok, dann versuche ich mich mal daran. Danke schön für den Hinweis...
vg
Bin auch gerade mal wieder dazu gekommen mein fhem zu updaten. Es läuft erstmal alles wie gewohnt. Keine Probleme mit CUL_HM.
Danke euch und Gruß Hoppel
Hallo Martin,
die Probleme bei dem Selbstbau Firmware Device sind ebenfalls durch deinen Hinweis behoben. Es lag nicht am Namen
des *.pm Files (das hatte ich bereits in HM_LC_Sw1PBU_FM.pm umbenannt, sondern an:
Zitat
InternalTimer(gettimeofday()+10,"registerHM_LC_Sw1PBU_FM_CustomFW","nothing", 0);
-siehe mein Beitrag-
Dieser Aufruf musste wohl ohne Verzögerung passieren, dann werden subTypes etc. auch richtig gesetzt.
Nochmals Danke, das Update der Homematic Komponenten funktioniert jetzt tadellos.
VG
mcfly
Hallo Martin,
seit dem letzten Update auf HMConfig.pm 19143 bekomme ich wieder folgende Meldungen im Log.
2019.04.10 08:01:48 1: PERL WARNING: Use of uninitialized value $mtId in hash element at FHEM/HMConfig.pm line 349, <$fh> line 187.
2019.04.10 08:01:48 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at FHEM/HMConfig.pm line 1842, <$fh> line 187.
Sicherlich wieder nur Kosmetik, aber vielleicht einfach zu beseitigen :)
Danke & Gruß
Fabian
Zitat von: webdandy am 10 April 2019, 08:07:49
Hallo Martin,
seit dem letzten Update auf HMConfig.pm 19143 bekomme ich wieder folgende Meldungen im Log.
2019.04.10 08:01:48 1: PERL WARNING: Use of uninitialized value $mtId in hash element at FHEM/HMConfig.pm line 349, <$fh> line 187.
2019.04.10 08:01:48 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at FHEM/HMConfig.pm line 1842, <$fh> line 187.
Sicherlich wieder nur Kosmetik, aber vielleicht einfach zu beseitigen :)
Danke & Gruß
Fabian
Es ist wohl etwas gravierender beim aktuellen Update, siehe https://forum.fhem.de/index.php/topic,99431.0.html
Erledigt
test mit svn-trunk 19154: i.O.
Danke!
Hm,
mit fhem-update funktioniert der HM-LC-Sw4-Ba-PCB doch noch nicht.
Es funzt nur Kanal 1, der Rest ist "unreachable".
HM-LC-Sw4-DR-2 geht mit allen 4 Kanälen
hab gestern aus trunk
10_CUL_HM.pm
HMConfig.pm
rübergespielt und das hat funktioniert. keine ahnung warum, vielleicht kein ordentliches reload/restart durchgeführt...
Kannst du bitte nochmal schauen?
Grüße!
Zitatmit fhem-update funktioniert der HM-LC-Sw4-Ba-PCB doch noch nicht.
Kann ich bestätigen, siehe https://forum.fhem.de/index.php/topic,99431.msg929135.html#msg929135
Zitat von: knopf_piano am 11 April 2019, 07:58:28
mit fhem-update funktioniert der HM-LC-Sw4-Ba-PCB doch noch nicht.
Meine funktionieren nach dem Update heute frueh auch nicht mehr. Kann ich etwas zur Fehlersuche beitragen?
Gruss Helmut
Ist das nur der sw4-ba-pcb?
Hattet ihr schon den update gemacht? Hatte das Device schon ein attr .mId?
Ihr konnt das Model mit SW4 anstelle von Sw4 schreiben. Das müsste es sein.
Ich werds wohl einbauen dass alles gross geschrieben wird.
Beim mir ist ein HM-LC-Sw4-DR-2 betroffen. Ein anderer HM-LC-Sw4-DR-2 mit derselben Firmware 2.4 ist nicht betroffen.
habe modelforce ergänzt, .mId zusätzlich.
weiterhin Fehlverhalten... kanal_1 geht, 2-4 nicht
Gesendet von meinem SM-J510FN mit Tapatalk
Zitat von: martinp876 am 11 April 2019, 20:52:24
Ist das nur der sw4-ba-pcb?
Hattet ihr schon den update gemacht? Hatte das Device schon ein attr .mId?
Ihr konnt das Model mit SW4 anstelle von Sw4 schreiben. Das müsste es sein.
Ich werds wohl einbauen dass alles gross geschrieben wird.
Ist das nur der sw4-ba-pcb? Ich habe nur hier MISSING_ACK gesehen.
Gestern Update gemacht, nach Fehler Restore mit fhem.save.
Zitatmodel HM-LC-SW4-BA-PCB, vor dem Update
mId 00AB, keine bei den Channel-Devices
Zitat von: martinp876 am 11 April 2019, 20:52:24
Ist das nur der sw4-ba-pcb?
Andere Fehlfunktionen sehe ich nicht.
Zitat von: martinp876 am 11 April 2019, 20:52:24Hattet ihr schon den update gemacht?
Eben ein Update durchgefuehrt.
HMConfig.pm 19154 2019-04-10 18:34:18Z martinp876 Zitat von: martinp876 am 11 April 2019, 20:52:24Hatte das Device schon ein attr .mId?Ihr konnt das Model mit SW4 anstelle von Sw4 schreiben. Das müsste es sein. Ich werds wohl einbauen dass alles gross geschrieben wird.
.mId 00AB
firmware 1.1
model HM-LC-SW4-BA-PCB Das Verhalten fuer alle vier Kanaele hat sich nicht geaendert.
2019-04-12 12:32:31.480 CUL_HM rel_wozi_01_Sw1 set_on
2019-04-12 12:32:31.556 CUL_HM rel_wozi_01_Sw1 trigLast: fhem:02
2019-04-12 12:32:31.626 CUL_HM rel_wozi_01_Sw1 trigLast: fhem:02
2019-04-12 12:32:40.258 CUL_HM rel_wozi_01 ResndFail
2019-04-12 12:32:40.277 CUL_HM rel_wozi_01 CMDs_done_Errors:1
2019-04-12 12:32:40.298 CUL_HM rel_wozi_01 MISSING ACKGruss Helmut
mit dem Update morgen sollte es nun gehen - model ist dann case insensitive. Attr Model sollte nach dem update und neustart alles Großbuchstaben sein.
Hi martinp876,
Habe update trunk gemacht
# $Id: 10_CUL_HM.pm 19161 2019-04-12 17:02:49Z martinp876 $
# $Id: HMConfig.pm 19162 2019-04-12 17:03:26Z martinp876 $
fhem-restart.
Geht leider immer noch nicht.
weiterhin Fehlverhalten... kanal_1 geht, 2-4 nicht
Es liegt an der Version HMConfig.pm. Diese Konstellation funktioniert
# $Id: 10_CUL_HM.pm 19161 2019-04-12 17:02:49Z martinp876 $
# $Id: HMConfig.pm 19119 2019-04-05 15:52:43Z martinp876 $
aktuelles Listing vom device
Internals:
DEF 447695
FUUID 5c4c1adb-f33f-35e2-99b5-c22f30885f91e83b
FVERSION 10_CUL_HM.pm:0.191610/2019-04-12
IODev HMLAN1
NAME Statusanzeige
NOTIFYDEV global
NR 4476
NTFY_ORDER 50-Statusanzeige
STATE MISSING ACK
TYPE CUL_HM
channel_01 Abfall_StatusLED
channel_02 Garagentor_StatusLED
channel_03 AlleFenster_StatusLED
channel_04 Alarmanlage_StatusLED
protCmdDel 18
protResnd 6 last_at:2019-04-12 20:10:05
protResndFail 6 last_at:2019-04-12 20:10:09
protSnd 6 last_at:2019-04-12 20:09:56
protState CMDs_done_Errors:1
READINGS:
2019-01-04 04:26:22 D-firmware 1.1
2019-01-04 04:26:22 D-serialNr NEQ0026223
2019-04-08 21:59:43 PairedTo 0x26EDF4
2019-01-04 05:45:30 R-pairCentral 0x26EDF4
2019-04-08 21:59:43 RegL_00. 00:00 02:01 05:00 0A:26 0B:ED 0C:F4 18:00
2019-04-12 20:04:09 battery ok
2019-04-08 21:03:59 level 0
2019-04-08 21:03:59 pct 0
2019-04-08 21:03:59 powerOn 2019-04-08 21:03:59
2019-04-08 21:03:59 recentStateType info
2019-04-12 20:10:09 state MISSING ACK
2019-04-08 21:03:59 timedOn off
helper:
HM_CMDNR 80
cSnd 1126EDF44476950201000000,1126EDF44476950204C80000
mId 00AB
peerFriend
peerOpt -:switch
regLst 0
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +447695,00,00,00
prefIO
rxt 0
vccu
p:
447695
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
model HM-LC-SW4-BA-PCB
modelForce HM-LC-SW4-BA-PCB
msgRepeat 1
room hidden
serialNr NEQ0026223
subType switch
webCmd getConfig:clear msgEvents
Also wenn ich eines neu anlege sjnd es 4 Kanäle.
Sollte bei dir auch klappen.
Muss ich noch einmal genau anschauen. Wenn der Kanal manuell entfernt wurde lege ich ihn nicht wieder an. Jedenfalls bestmöglich.
Lege den kanal manuell an.
Nachgefragt:
Es sind 4 kanäle angelegt, so weit ok. Was ist dann "geht"? Und viel mehr was ist "geht nicht"? Zumindest 1 detail:
Kommando fehlt
Komando geht nicht
Reading fehlt
Reading ist falsch
Get deviceinfo
Und
Get cmdList
Und
Get reglist
Sollten dir zeigen was verfügbar ist, ausser readings.
Heute auch ein Update gemacht.
Es geht kein Schalten beim HM-LC-SW4-BA-PCB mehr (Set on/off/on-for-timer). Endet alles mit einem MISSING ACK. Schalten mit gepeerter Fernbedienung funktioniert und wird in fhem auch entsprechend angezeigt. Anbei ein List vom Device.
Brauchst du noch etwas?
Device name:AU_Garten_Wasser
mId :00AB Model=HM-LC-SW4-BA-PCB
mode :normal
protState : CMDs_done_Errors:1 pending: none
Edit: die Kanäle sind aber alle da und der Status wird auch richtig angezeigt.
Internals:
DEF 447740
FUUID 5c4b9c80-f33f-5091-8b8c-ed0e123bae433c44
FVERSION 10_CUL_HM.pm:0.191740/2019-04-13
HmLGW1_MSGCNT 7
HmLGW1_RAWMSG 050100338EA4104477408D0C2D0604000000
HmLGW1_RSSI -51
HmLGW1_TIME 2019-04-14 10:02:30
HmUART1_MSGCNT 7
HmUART1_RAWMSG 050000478EA4104477408D0C2D0604000000
HmUART1_RSSI -71
HmUART1_TIME 2019-04-14 10:02:30
IODev HmLGW1
LASTInputDev HmLGW1
MSGCNT 14
NAME AU_Garten_Wasser
NOTIFYDEV global
NR 234
NTFY_ORDER 50-AU_Garten_Wasser
STATE MISSING ACK
TYPE CUL_HM
channel_01 AU_Garten_Wasser_Sw_01
channel_02 AU_Garten_Wasser_Sw_02
channel_03 AU_Garten_Wasser_Sw_03
channel_04 AU_Garten_Wasser_Sw_04
protCmdDel 3
protResnd 1 last_at:2019-04-14 11:26:46
protResndFail 1 last_at:2019-04-14 11:26:51
protSnd 1 last_at:2019-04-14 11:26:42
protState CMDs_done_Errors:1
rssi_at_HmLGW1 cnt:7 min:-51 max:-51 avg:-51 lst:-51
rssi_at_HmUART1 cnt:7 min:-71 max:-70 avg:-70.71 lst:-71
READINGS:
from archivexx D-firmware 1.1
from archivexx D-serialNr NEQ0027127
2018-07-01 18:54:32 PairedTo 0x8D0C2D
2017-11-21 15:22:15 R-intKeyVisib invisib
2017-11-21 15:22:15 R-ledMode on
2017-11-21 15:22:15 R-localResDis off
2017-11-21 15:22:15 R-pairCentral 0x8D0C2D
2018-07-01 18:54:32 RegL_00. 02:01 05:40 0A:8D 0B:0C 0C:2D 18:00 00:00
2019-04-14 10:02:30 battery ok
2018-07-01 18:54:28 level 0
2018-07-01 18:54:28 pct 0
2018-07-01 18:54:28 powerOn 2018-07-01 18:54:28
2018-07-01 18:54:28 recentStateType info
2019-04-14 11:26:51 state MISSING ACK
2018-07-01 18:54:28 timedOn off
helper:
HM_CMDNR 144
cSnd 118D0C2D4477400201C800008CA4,118D0C2D4477400201000000
mId 00AB
peerFriend
peerOpt -:switch
regLst 0
rxType 1
supp_Pair_Rep 0
tmplChg 0
ack:
expert:
def 1
det 1
raw 1
tpl 0
io:
newChn +447740,00,03,00
nextSend 1555228950.31603
prefIO
rxt 0
vccu VCCU
p:
447740
00
03
00
mRssi:
mNo 8E
io:
HmLGW1:
-45
-45
HmUART1:
-71
-71
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rpt:
IO HmUART1
flg A
ts 1555228949.99114
ack:
HASH(0x4984290)
8E80028D0C2D44774000
rssi:
at_HmLGW1:
avg -51
cnt 7
lst -51
max -51
min -51
at_HmUART1:
avg -70.7142857142857
cnt 7
lst -71
max -70
min -71
shadowReg:
tmpl:
Attributes:
IODev HmUART1
IOgrp VCCU
autoReadReg 4_reqStatus
expert 3_allReg+raw
firmware 1.1
icon sani_sprinkling
model HM-LC-SW4-BA-PCB
msgRepeat 1
room Unsorted
serialNr NEQ0027127
subType switch
webCmd getConfig:clear msgEvents
Ich hatte ein identisches Problem mit einem HM-LC-Sw1-DR-2 (4fach Aktor Hutschiene) - dort war nur noch Kanal1 vorhanden.
Aus der ConfigDB die Definition für Kanal2 gesucht, wieder eingefügt - danach waren alle Kanäle wieder vorhanden und die Probleme weg.
Meinen Wandschalter kann ich immer noch nicht anlernen:
2019.04.14 13:19:46 3: CUL_HM set VCCU hmPairForSec 600
2019.04.14 13:20:07 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:20:07 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4476.
2019.04.14 13:20:07 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1485.
2019.04.14 13:20:07 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1486.
2019.04.14 13:20:07 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1530.
2019.04.14 13:20:07 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:20:07 3: HM_HMLAN1: Unknown code A1A6584006649B30000002800694F45513233303636383610010100::-82:HM_HMLAN1, help me!
2019.04.14 13:20:07 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:20:07 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:20:07 3: HM_HMLAN2: Unknown code A1A6584006649B30000002800694F45513233303636383610010100::-63:HM_HMLAN2, help me!
2019.04.14 13:20:07 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:20:07 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:20:07 3: HM_HMLAN3: Unknown code A1A6584006649B30000002800694F45513233303636383610010100::-46:HM_HMLAN3, help me!
2019.04.14 13:20:10 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/66_EseraDigitalInOut.pm line 560.
2019.04.14 13:20:10 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/66_EseraAnalogInOut.pm line 456.
2019.04.14 13:20:10 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/66_EseraTemp.pm line 126.
2019.04.14 13:20:31 1: Error: >< has no TYPE, but following keys: >helper<
2019.04.14 13:21:04 3: CUL_HM set VCCU hmPairForSec 600
2019.04.14 13:21:22 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:21:22 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:21:22 3: HM_HMLAN1: Unknown code A1A6684006649B30000002800694F45513233303636383610010100::-65:HM_HMLAN1, help me!
2019.04.14 13:21:22 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:21:22 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:21:22 3: HM_HMLAN3: Unknown code A1A6684006649B30000002800694F45513233303636383610010100::-46:HM_HMLAN3, help me!
2019.04.14 13:21:22 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:21:22 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.14 13:21:22 3: HM_HMLAN2: Unknown code A1A6684006649B30000002800694F45513233303636383610010100::-71:HM_HMLAN2, help me!
2019.04.14 13:21:23 1: Error: >< has no TYPE, but following keys: >helper<
2019.04.14 13:23:57.229 0: HMLAN_Parse: HM_HMLAN1 R:E35C61D stat:0000 t:0F176AAC d:FF r:FFC7 m:84 8470 35C61D 000000 00D928
2019.04.14 13:23:57.684 0: HMLAN_Parse: HM_HMLAN1 R:E38F0FF stat:0000 t:0F176C75 d:FF r:FFC7 m:8F 8610 38F0FF 000000 0AA0CA0A0E00
2019.04.14 13:23:59.681 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:0F177441 d:FF r:FFBE m:5D 8470 45786F 000000 007636
2019.04.14 13:24:01.543 0: HMLAN_Parse: HM_HMLAN1 R:E34B24B stat:0000 t:0F177B89 d:FF r:FFCC m:1D 865A 34B24B 000000 A8DC23
2019.04.14 13:24:03.031 0: HMLAN_Parse: HM_HMLAN1 R:E34AFFC stat:0000 t:0F178157 d:FF r:FFC3 m:CF 865A 34AFFC 000000 98C235
2019.04.14 13:24:03.133 0: HMLAN_Parse: HM_HMLAN1 R:E375D5E stat:0000 t:0F1781BF d:FF r:FFC6 m:AD 8470 375D5E 000000 00CB2C
2019.04.14 13:24:04.284 0: HMLAN_Parse: HM_HMLAN1 R:E35EB59 stat:0000 t:0F17863D d:FF r:FFB4 m:0A 8470 35EB59 000000 80D932
2019.04.14 13:24:06.201 0: HMLAN_Parse: HM_HMLAN1 R:E2E61DA stat:0000 t:0F178DBA d:FF r:FFC1 m:85 8610 2E61DA 000000 0AA0CB100800
2019.04.14 13:24:07.144 0: HMLAN_Parse: HM_HMLAN1 R:E35A426 stat:0000 t:0F17916A d:FF r:FFCB m:4F 865A 35A426 000000 98D828
2019.04.14 13:24:07.157 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: 4F 86 5A 35A426 000000 98D828
2019.04.14 13:24:07.233 0: HMLAN_Parse: HM_HMLAN1 R:E323F16 stat:0000 t:0F1791C3 d:FF r:FFC0 m:77 8670 323F16 000000 009E2F
2019.04.14 13:24:07.285 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:0F1791F7 d:FF r:FFBF m:EE 865A 3F2E6A 000000 9CCD28
2019.04.14 13:24:07.293 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 35 msg: EE 86 5A 3F2E6A 000000 9CCD28
2019.04.14 13:24:07.930 0: HMLAN_Parse: HM_HMLAN1 R:E3BD1F4 stat:0000 t:0F17947E d:FF r:FFC2 m:27 8653 3BD1F4 000000 22C3DD3C05C5B5
2019.04.14 13:24:08.899 0: HMLAN_Parse: HM_HMLAN1 R:E2E1DC0 stat:0000 t:0F179846 d:FF r:FFBF m:7B 8610 2E1DC0 000000 0AA4D30F0000
2019.04.14 13:24:08.910 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3B msg: 7B 86 10 2E1DC0 000000 0AA4D30F0000
2019.04.14 13:24:14.936 0: HMLAN_Send: HM_HMLAN1 I:K
2019.04.14 13:24:14.939 0: HMLAN_Parse: HM_HMLAN1 V:03C5 sNo:LEQ0384706 d:29A0A6 O:1A2B3C t:0F17AFEB IDcnt:0007 L:1 %
2019.04.14 13:24:16.121 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.14 13:24:16.141 0: HMUARTLGW HM_HMLAN2 recv: 00 040204, state 98
2019.04.14 13:24:16.141 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.14 13:24:16.141 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0199
2019.04.14 13:24:18.890 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.14 13:24:18.909 0: HMUARTLGW HM_HMLAN3 recv: 00 040200, state 98
2019.04.14 13:24:18.909 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.14 13:24:18.909 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0182
2019.04.14 13:24:19.166 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Kdf
2019.04.14 13:24:19.185 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Kdf
2019.04.14 13:24:21.543 0: HMLAN_Parse: HM_HMLAN1 R:E34B24B stat:0000 t:0F17C9AE d:FF r:FFCC m:1D 8470 34B24B 000000 00DC23
2019.04.14 13:24:21.553 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3C msg: 1D 84 70 34B24B 000000 00DC23
2019.04.14 13:24:21.554 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 47 msg: 1D 84 70 34B24B 000000 00DC23
2019.04.14 13:24:23.030 0: HMLAN_Parse: HM_HMLAN1 R:E34AFFC stat:0000 t:0F17CF7B d:FF r:FFC3 m:CF 8470 34AFFC 000000 00C235
2019.04.14 13:24:23.037 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 36 msg: CF 84 70 34AFFC 000000 00C235
2019.04.14 13:24:23.037 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 41 msg: CF 84 70 34AFFC 000000 00C235
2019.04.14 13:24:24.956 0: HMLAN_Parse: HM_HMLAN1 R:E3BD11A stat:0000 t:0F17D702 d:FF r:FFC2 m:A4 865E 3BD11A 000000 1AA33E013D30
2019.04.14 13:24:24.966 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 30 msg: A4 86 5E 3BD11A 000000 1AA33E013D30
2019.04.14 13:24:24.966 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 36 msg: A4 86 5E 3BD11A 000000 1AA33E013D30
2019.04.14 13:24:25.682 0: HMLAN_Parse: HM_HMLAN1 R:E44EEB2 stat:0000 t:0F17D9D8 d:FF r:FFB5 m:EE 8610 44EEB2 000000 0AA4D30E0000
2019.04.14 13:24:25.693 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 34 msg: EE 86 10 44EEB2 000000 0AA4D30E0000
2019.04.14 13:24:25.693 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 37 msg: EE 86 10 44EEB2 000000 0AA4D30E0000
2019.04.14 13:24:27.145 0: HMLAN_Parse: HM_HMLAN1 R:E35A426 stat:0000 t:0F17DF8F d:FF r:FFCC m:4F 8470 35A426 000000 00D828
2019.04.14 13:24:27.153 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: 4F 84 70 35A426 000000 00D828
2019.04.14 13:24:27.153 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3F msg: 4F 84 70 35A426 000000 00D828
2019.04.14 13:24:27.284 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:0F17E01A d:FF r:FFC0 m:EE 8470 3F2E6A 000000 00CD28
2019.04.14 13:24:27.293 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: EE 84 70 3F2E6A 000000 00CD28
2019.04.14 13:24:27.293 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3A msg: EE 84 70 3F2E6A 000000 00CD28
2019.04.14 13:24:29.186 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Ke0
2019.04.14 13:24:29.204 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Ke0
2019.04.14 13:24:31.123 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.14 13:24:31.144 0: HMUARTLGW HM_HMLAN2 recv: 00 040204, state 98
2019.04.14 13:24:31.144 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.14 13:24:31.145 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0214
2019.04.14 13:24:32.849 0: HMLAN_Parse: HM_HMLAN1 R:E5E144B stat:0000 t:0F17F5D8 d:FF r:FFBB m:B4 8410 5E144B 1A2B3C 0601A700
2019.04.14 13:24:32.856 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: B4 84 10 5E144B 1A2B3C 0601A700
2019.04.14 13:24:32.857 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 45 msg: B4 84 10 5E144B 1A2B3C 0601A700
2019.04.14 13:24:33.892 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.14 13:24:33.908 0: HMUARTLGW HM_HMLAN3 recv: 00 040200, state 98
2019.04.14 13:24:33.908 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.14 13:24:33.908 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0159
2019.04.14 13:24:34.489 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:0F17FC40 d:FF r:FFC3 m:67 8400 6649B3 000000 2800694F45513233303636383610010100
2019.04.14 13:24:34.501 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 30 msg: 67 84 00 6649B3 000000 2800694F45513233303636383610010100
2019.04.14 13:24:34.503 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3E msg: 67 84 00 6649B3 000000 2800694F45513233303636383610010100
2019.04.14 13:24:39.205 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Ke1
2019.04.14 13:24:39.224 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Ke1
2019.04.14 13:24:39.937 0: HMLAN_Send: HM_HMLAN1 I:K
2019.04.14 13:24:39.940 0: HMLAN_Parse: HM_HMLAN1 V:03C5 sNo:LEQ0384706 d:29A0A6 O:1A2B3C t:0F181198 IDcnt:0007 L:1 %
2019.04.14 13:24:40.315 0: HMLAN_Parse: HM_HMLAN1 R:E3F2D76 stat:0000 t:0F181304 d:FF r:FFC8 m:73 865A 3F2D76 000000 A8D226
2019.04.14 13:24:40.325 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3D msg: 73 86 5A 3F2D76 000000 A8D226
2019.04.14 13:24:46.125 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.14 13:24:46.144 0: HMUARTLGW HM_HMLAN2 recv: 00 040204, state 98
2019.04.14 13:24:46.144 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.14 13:24:46.144 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0187
2019.04.14 13:24:46.543 0: HMLAN_Parse: HM_HMLAN1 R:E38E510 stat:0000 t:0F182B59 d:FF r:FFC0 m:73 8610 38E510 000000 0AA0CA090E00
2019.04.14 13:24:46.552 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 36 msg: 73 86 10 38E510 000000 0AA0CA090E00
2019.04.14 13:24:46.553 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2A msg: 73 86 10 38E510 000000 0AA0CA090E00
2019.04.14 13:24:48.332 0: HMLAN_Parse: HM_HMLAN1 R:E44FEA4 stat:0000 t:0F183256 d:FF r:FFC8 m:EB 8610 44FEA4 000000 0AA8D7090A00
2019.04.14 13:24:48.340 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 4E msg: EB 86 10 44FEA4 000000 0AA8D7090A00
2019.04.14 13:24:48.340 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 40 msg: EB 86 10 44FEA4 000000 0AA8D7090A00
2019.04.14 13:24:48.465 1: Error: >< has no TYPE, but following keys: >helper<
2019.04.14 13:24:49.057 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.14 13:24:49.076 0: HMUARTLGW HM_HMLAN3 recv: 00 040200, state 98
2019.04.14 13:24:49.076 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.14 13:24:49.076 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0184
2019.04.14 13:24:49.225 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Ke2
2019.04.14 13:24:49.244 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Ke2
2019.04.14 13:24:50.717 0: HMLAN_Parse: HM_HMLAN1 R:E2E96A1 stat:0000 t:0F183BA8 d:FF r:FFC3 m:AF 8610 2E96A1 000000 0AA0CD0E0C00
2019.04.14 13:24:50.728 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 34 msg: AF 86 10 2E96A1 000000 0AA0CD0E0C00
2019.04.14 13:24:50.728 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 42 msg: AF 86 10 2E96A1 000000 0AA0CD0E0C00
2019.04.14 13:24:51.474 0: HMLAN_Parse: HM_HMLAN1 R:E286865 stat:0000 t:0F183E9D d:FF r:FFBA m:7B 845E 286865 000000 8B25C5000D9A00FD092601
2019.04.14 13:24:51.478 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: 7B 84 5E 286865 000000 8B25C5000D9A00FD092601
2019.04.14 13:24:51.479 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 46 msg: 7B 84 5E 286865 000000 8B25C5000D9A00FD092601
2019.04.14 13:24:59.245 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Ke3
2019.04.14 13:24:59.263 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Ke3
2019.04.14 13:25:00.157 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 4A msg: 50 86 5A 31D1FD 000000 A4C02E
2019.04.14 13:25:00.158 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3A msg: 50 86 5A 31D1FD 000000 A4C02E
2019.04.14 13:25:00.324 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3D msg: 73 84 70 3F2D76 000000 00D226
2019.04.14 13:25:01.055 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 42 msg: 7A 86 5A 31DA16 000000 A4D327
2019.04.14 13:25:01.056 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 7A 86 5A 31DA16 000000 A4D327
2019.04.14 13:25:01.127 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.14 13:25:01.147 0: HMUARTLGW HM_HMLAN2 recv: 00 040204, state 98
2019.04.14 13:25:01.147 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.14 13:25:01.148 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0203
2019.04.14 13:25:01.519 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3E msg: 73 84 5E 55F9C6 000000 31083100000000000923FF
2019.04.14 13:25:01.520 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3C msg: 73 84 5E 55F9C6 000000 31083100000000000923FF
2019.04.14 13:25:04.059 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.14 13:25:04.080 0: HMUARTLGW HM_HMLAN3 recv: 00 040200, state 98
2019.04.14 13:25:04.080 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.14 13:25:04.080 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0199
2019.04.14 13:25:07.844 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3A msg: 53 86 5A 45EBEB 000000 A8D726
2019.04.14 13:25:07.912 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3E msg: F7 86 10 313583 000000 0A98C2090500
2019.04.14 13:25:09.264 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Ke4
2019.04.14 13:25:09.284 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Ke4
2019.04.14 13:25:10.099 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3A msg: 52 84 10 31D1FD 000000 0BA4C00E00
2019.04.14 13:25:10.636 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 49 msg: E4 86 5A 31FF57 000000 A8D22A
2019.04.14 13:25:12.112 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: 0E 86 5A 314230 000000 A0D025
Danke, -MN
Hallo zusammen
Ich habe diese Beiträge nach gestrigen Fhem Problemen verfolgt. Ich muss mich erstmal wundern wie scharf da so kritisiert wird. Ich denke Fhem hat weniger Bug's als Windows und ist zudem kostenlos, also sollten die Entwickler bedankt werden für Ihre Arbeit, und nur so nebenbei: Wer arbeitet macht Fehler und wer keine macht hat noch nie gearbeitet.
Das musste ich einmal loswerden sorry. Jetzt zu meinem Problem.
Nach dem gestrigen Update wo ja die CUL_HM dabei war hatte ich in den Funksteckdosen (powerMeter) witzigerweise kein set on bzw off mehr sondern nur press. Das hatte natürlich zur folge das nichts mehr schaltete. Ich hab dann heute morgen mein backup eingespielt so das erstmal wieder alles läuft.
Meine Frage ist jetzt ist dieses Phänomen bekannt? Wenn ist es schon behoben oder warte ich besser mit einem erneuten update?
Viele grüße Helmuth
Zitat von: steffenp am 14 April 2019, 12:58:05
Heute auch ein Update gemacht.
Es geht kein Schalten beim HM-LC-SW4-BA-PCB mehr (Set on/off/on-for-timer). Endet alles mit einem MISSING ACK. Schalten mit gepeerter Fernbedienung funktioniert und wird in fhem auch entsprechend angezeigt. Anbei ein List vom Device.
Brauchst du noch etwas?
Device name:AU_Garten_Wasser
mId :00AB Model=HM-LC-SW4-BA-PCB
mode :normal
protState : CMDs_done_Errors:1 pending: none
Edit: die Kanäle sind aber alle da und der Status wird auch richtig angezeigt.
Internals:
DEF 447740
FUUID 5c4b9c80-f33f-5091-8b8c-ed0e123bae433c44
FVERSION 10_CUL_HM.pm:0.191740/2019-04-13
HmLGW1_MSGCNT 7
HmLGW1_RAWMSG 050100338EA4104477408D0C2D0604000000
HmLGW1_RSSI -51
HmLGW1_TIME 2019-04-14 10:02:30
HmUART1_MSGCNT 7
HmUART1_RAWMSG 050000478EA4104477408D0C2D0604000000
HmUART1_RSSI -71
HmUART1_TIME 2019-04-14 10:02:30
IODev HmLGW1
LASTInputDev HmLGW1
MSGCNT 14
NAME AU_Garten_Wasser
NOTIFYDEV global
NR 234
NTFY_ORDER 50-AU_Garten_Wasser
STATE MISSING ACK
TYPE CUL_HM
channel_01 AU_Garten_Wasser_Sw_01
channel_02 AU_Garten_Wasser_Sw_02
channel_03 AU_Garten_Wasser_Sw_03
channel_04 AU_Garten_Wasser_Sw_04
protCmdDel 3
protResnd 1 last_at:2019-04-14 11:26:46
protResndFail 1 last_at:2019-04-14 11:26:51
protSnd 1 last_at:2019-04-14 11:26:42
protState CMDs_done_Errors:1
rssi_at_HmLGW1 cnt:7 min:-51 max:-51 avg:-51 lst:-51
rssi_at_HmUART1 cnt:7 min:-71 max:-70 avg:-70.71 lst:-71
READINGS:
from archivexx D-firmware 1.1
from archivexx D-serialNr NEQ0027127
2018-07-01 18:54:32 PairedTo 0x8D0C2D
2017-11-21 15:22:15 R-intKeyVisib invisib
2017-11-21 15:22:15 R-ledMode on
2017-11-21 15:22:15 R-localResDis off
2017-11-21 15:22:15 R-pairCentral 0x8D0C2D
2018-07-01 18:54:32 RegL_00. 02:01 05:40 0A:8D 0B:0C 0C:2D 18:00 00:00
2019-04-14 10:02:30 battery ok
2018-07-01 18:54:28 level 0
2018-07-01 18:54:28 pct 0
2018-07-01 18:54:28 powerOn 2018-07-01 18:54:28
2018-07-01 18:54:28 recentStateType info
2019-04-14 11:26:51 state MISSING ACK
2018-07-01 18:54:28 timedOn off
helper:
HM_CMDNR 144
cSnd 118D0C2D4477400201C800008CA4,118D0C2D4477400201000000
mId 00AB
peerFriend
peerOpt -:switch
regLst 0
rxType 1
supp_Pair_Rep 0
tmplChg 0
ack:
expert:
def 1
det 1
raw 1
tpl 0
io:
newChn +447740,00,03,00
nextSend 1555228950.31603
prefIO
rxt 0
vccu VCCU
p:
447740
00
03
00
mRssi:
mNo 8E
io:
HmLGW1:
-45
-45
HmUART1:
-71
-71
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rpt:
IO HmUART1
flg A
ts 1555228949.99114
ack:
HASH(0x4984290)
8E80028D0C2D44774000
rssi:
at_HmLGW1:
avg -51
cnt 7
lst -51
max -51
min -51
at_HmUART1:
avg -70.7142857142857
cnt 7
lst -71
max -70
min -71
shadowReg:
tmpl:
Attributes:
IODev HmUART1
IOgrp VCCU
autoReadReg 4_reqStatus
expert 3_allReg+raw
firmware 1.1
icon sani_sprinkling
model HM-LC-SW4-BA-PCB
msgRepeat 1
room Unsorted
serialNr NEQ0027127
subType switch
webCmd getConfig:clear msgEvents
Ich habe das selbe Problem mit dem HM-LC-SW4-BA-PCB.
Auch ein Update aus dem SVN von heute hat leider keine Besserung gebracht.
@Steffenp
ist gelöst. Ich hatte den Burst-mode für das und das Sw1-BA abgeklemmt. Sorry.
Bitte beide (CUL_HM und HMConfig) neu laden. Update erst morgen
@Helmuth:
nun, hier muss ich schon kritik entgegennehmen. Der Erste Versuch hätte zwar klappen können... aber diesmal hätte ich länger testen müssen. Hat so einfach ausgesehen - sorry an alle.
@Morgennebel:
Pairen schaue ich mir gleich an.
Danke, Martin,
von meiner Seite aus bin ich froh, daß es FHEM gibt und selbst "veraltete" Technologie wie HM noch aktiv von der Software weiterentwickelt wird.
Kein Gemecker von meiner Seite. Danke für das Lösen der Probleme...
Ciao, -MN
Danke, teste ich morgen mit dem normalen Update. Ist bei mir nicht so eilig, noch wird nicht gesprengt.
Was mir noch auffällt, seit dem Update wirft der ActionDetector die events IOopen: 0 und IOs_ok kurz hintereinander alle ca. 10 min. Das war vorher nicht so.
Ist das ein Problem bei mir oder muss das so sein?
Gesendet von meinem BAH-W09 mit Tapatalk
Hallo Martin
Vielen Dank für Deine schnelle Antwort und Lösung.
Ich werde auch bis morgen warten, es läuft ja alles.
Wie schon gesagt so etwas kann passieren und ist dank backup kein Problem.
Schönen Rest Sonntag noch.
Gruß Helmuth
@Morgennebel:
die warning sollten mit den Update erledigt sein. Unklar ist weiterhin, warum die message nicht "gefangen" wird.
kannsr du den Verbose-level auf 2 stellen und pairen?
Übrigens: Das Device sollte immer angelegt werden und beim 2. Mal ist die Meldung nich mehr vorhanden.
@Steffenp:
ActionDetector hat kein Event IOopen. Du redest von der vccu?
Zitat von: martinp876 am 14 April 2019, 19:52:35
@Steffenp:
ActionDetector hat kein Event IOopen. Du redest von der vccu?
Die Events sehen im Eventmonitor so aus:
2019-04-14 21:24:25 CUL_HM ActionDetector IOopen: 0
2019-04-14 21:24:25 CUL_HM ActionDetector IOs_ok
Wo die Ursache liegt ist eine andere Frage.
Gruß und Danke
Gesendet von meinem SM-G960F mit Tapatalk
Zitat von: martinp876 am 14 April 2019, 19:52:35
@Morgennebel:
kannsr du den Verbose-level auf 2 stellen und pairen?
Global, VCCU oder die IOS?
Danke, -MN
Die Lösung meines Problems gestern (Bezug CUL_HM und HMConfig) hat durch update force zusätzlich noch ein anderes "Problem" gelöst, das sich seit etwa drei Wochen nach einem Update wieder eingeschlichen hatte:
FHEMWEB SSL/HTTPS error: SSL connect accept failed because of handshake problems error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
Das ist zwar halb OT, aber dennoch eventuell für den Einen oder Anderen ein Anstoß, mal alles neu zu holen.
Ich bin übrigens auch sehr dankbar, dass ihr als Programmierer Weiterentwicklung und Bugbehebung betreibt! Ich sehe das Forum auch als Plattform zur Rückmeldung der User und diese sollte sich wirklich im respektvollen Rahmen halten!
Mit dem heutigen Update sieht es so aus, dass der HM-LC-SW4-BA-PCB normal arbeitet.
Danke und schöne Feiertage
Kann ich bestätigen. Mein HM-LC-SW4-BA-PCB arbeitet auch wieder. Super Suport.
Auch die komischen Events sind wieder weg.....
Gruß
Gesendet von meinem SM-G960F mit Tapatalk
Hi,
update vom 16.4.2019
HM-LC-SW4-BA-PCB geht wieder.
Danke!
Gesendet von meinem SM-J510FN mit Tapatalk
Hi Martin,
hier noch ein Anlernversuch. Er scheitert immer noch (am Gerät blinkt die LED für 30 Sekunden und das Gerät taucht nicht im CUL_HM-Raum auf):
2019.04.16 16:07:38.950 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA94EB d:FF r:FFBE m:BC A010 3F2E6A 1A2B3C 035B20452045204520403C4E544F024120
2019.04.16 16:07:38.960 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: BC A0 10 3F2E6A 1A2B3C 035B20452045204520403C4E544F024120
2019.04.16 16:07:38.961 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: BC A0 10 3F2E6A 1A2B3C 035B20452045204520403C4E544F024120
2019.04.16 16:07:39.017 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.16 16:07:39.040 0: HMUARTLGW HM_HMLAN2 recv: 00 040216, state 98
2019.04.16 16:07:39.040 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.16 16:07:39.040 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0226
2019.04.16 16:07:39.060 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA955A d:FF r:FFBB m:BC 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.068 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: BC 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.208 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA95ED d:FF r:FFBF m:BD A010 3F2E6A 1A2B3C 036A452045204520452045204520452045
2019.04.16 16:07:39.220 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: BD A0 10 3F2E6A 1A2B3C 036A452045204520452045204520452045
2019.04.16 16:07:39.220 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: BD A0 10 3F2E6A 1A2B3C 036A452045204520452045204520452045
2019.04.16 16:07:39.319 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA965D d:FF r:FFBA m:BD 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.328 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: BD 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.467 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA96F0 d:FF r:FFBF m:BE A010 3F2E6A 1A2B3C 0379204520403C4E544F02412045204520
2019.04.16 16:07:39.476 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: BE A0 10 3F2E6A 1A2B3C 0379204520403C4E544F02412045204520
2019.04.16 16:07:39.476 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: BE A0 10 3F2E6A 1A2B3C 0379204520403C4E544F02412045204520
2019.04.16 16:07:39.577 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA975F d:FF r:FFBB m:BE 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.584 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: BE 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.726 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA97F3 d:FF r:FFBE m:BF A010 3F2E6A 1A2B3C 0388452045204520452045204520452040
2019.04.16 16:07:39.736 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: BF A0 10 3F2E6A 1A2B3C 0388452045204520452045204520452040
2019.04.16 16:07:39.736 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: BF A0 10 3F2E6A 1A2B3C 0388452045204520452045204520452040
2019.04.16 16:07:39.836 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9862 d:FF r:FFBB m:BF 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.844 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: BF 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:39.864 0: HMLAN_Parse: HM_HMLAN1 R:E3BD1F4 stat:0000 t:19FA987F d:FF r:FFC5 m:F8 8653 3BD1F4 000000 2463DB9C045FE9
2019.04.16 16:07:39.876 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 48 msg: F8 86 53 3BD1F4 000000 2463DB9C045FE9
2019.04.16 16:07:39.876 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 56 msg: F8 86 53 3BD1F4 000000 2463DB9C045FE9
2019.04.16 16:07:39.984 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA98F5 d:FF r:FFBE m:C0 A010 3F2E6A 1A2B3C 03973C4E544F0241204520452045204520
2019.04.16 16:07:39.996 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C0 A0 10 3F2E6A 1A2B3C 03973C4E544F0241204520452045204520
2019.04.16 16:07:39.996 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: C0 A0 10 3F2E6A 1A2B3C 03973C4E544F0241204520452045204520
2019.04.16 16:07:40.095 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9965 d:FF r:FFB9 m:C0 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:40.104 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C0 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:40.242 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA99F8 d:FF r:FFBE m:C1 A010 3F2E6A 1A2B3C 03A645204520452045204520403C4E544F
2019.04.16 16:07:40.252 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C1 A0 10 3F2E6A 1A2B3C 03A645204520452045204520403C4E544F
2019.04.16 16:07:40.253 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: C1 A0 10 3F2E6A 1A2B3C 03A645204520452045204520403C4E544F
2019.04.16 16:07:40.255 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.16 16:07:40.272 0: HMUARTLGW HM_HMLAN3 recv: 00 040201, state 98
2019.04.16 16:07:40.272 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.16 16:07:40.272 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0166
2019.04.16 16:07:40.354 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9A68 d:FF r:FFBB m:C1 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:40.360 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C1 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:40.393 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): K48
2019.04.16 16:07:40.412 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >K48
2019.04.16 16:07:40.502 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA9AFB d:FF r:FFBF m:C2 A010 3F2E6A 1A2B3C 03B5024120452045204520452045204520
2019.04.16 16:07:40.512 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C2 A0 10 3F2E6A 1A2B3C 03B5024120452045204520452045204520
2019.04.16 16:07:40.513 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: C2 A0 10 3F2E6A 1A2B3C 03B5024120452045204520452045204520
2019.04.16 16:07:40.611 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9B6A d:FF r:FFBB m:C2 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:40.620 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C2 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:40.757 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA9BFC d:FF r:FFBF m:C3 A010 3F2E6A 1A2B3C 03C4452045204520000000000000
2019.04.16 16:07:40.768 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C3 A0 10 3F2E6A 1A2B3C 03C4452045204520000000000000
2019.04.16 16:07:40.769 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: C3 A0 10 3F2E6A 1A2B3C 03C4452045204520000000000000
2019.04.16 16:07:40.870 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9C6D d:FF r:FFBB m:C3 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:40.880 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C3 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:41.005 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA9CF4 d:FF r:FFBF m:C4 8010 3F2E6A 1A2B3C 0300
2019.04.16 16:07:41.012 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C4 80 10 3F2E6A 1A2B3C 0300
2019.04.16 16:07:41.012 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: C4 80 10 3F2E6A 1A2B3C 0300
2019.04.16 16:07:41.094 0: HMUARTLGW HM_HMLAN2 send: 01 02 00 00 00 msg: C5 A0 01 1A2B3C 3F2E6A 02040000000009
2019.04.16 16:07:41.149 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9D84 d:FF r:FFBB m:C5 A001 1A2B3C 3F2E6A 02040000000009
2019.04.16 16:07:41.156 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C5 A0 01 1A2B3C 3F2E6A 02040000000009
2019.04.16 16:07:41.288 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA9E0F d:FF r:FFBE m:C5 A010 3F2E6A 1A2B3C 0301000000000000000000000000000000
2019.04.16 16:07:41.296 0: HMUARTLGW HM_HMLAN2 recv: 01 0402, state 100
2019.04.16 16:07:41.296 0: HMUARTLGW HM_HMLAN2 Ack: 02
2019.04.16 16:07:41.296 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: C5 A0 10 3F2E6A 1A2B3C 0301000000000000000000000000000000
2019.04.16 16:07:41.297 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C5 A0 10 3F2E6A 1A2B3C 0301000000000000000000000000000000
2019.04.16 16:07:41.400 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9E7F d:FF r:FFBA m:C5 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:41.408 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C5 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:41.546 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FA9F11 d:FF r:FFBF m:C6 A010 3F2E6A 1A2B3C 0310000000004520452045204520452045
2019.04.16 16:07:41.556 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C6 A0 10 3F2E6A 1A2B3C 0310000000004520452045204520452045
2019.04.16 16:07:41.556 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: C6 A0 10 3F2E6A 1A2B3C 0310000000004520452045204520452045
2019.04.16 16:07:41.657 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FA9F80 d:FF r:FFBB m:C6 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:41.664 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C6 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:41.816 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C7 A0 10 3F2E6A 1A2B3C 031F204520452045204520452045204520
2019.04.16 16:07:41.817 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: C7 A0 10 3F2E6A 1A2B3C 031F204520452045204520452045204520
2019.04.16 16:07:41.916 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA083 d:FF r:FFB9 m:C7 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:41.924 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C7 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.064 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA117 d:FF r:FFBE m:C8 A010 3F2E6A 1A2B3C 032E452045204520452045204520452045
2019.04.16 16:07:42.076 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C8 A0 10 3F2E6A 1A2B3C 032E452045204520452045204520452045
2019.04.16 16:07:42.076 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: C8 A0 10 3F2E6A 1A2B3C 032E452045204520452045204520452045
2019.04.16 16:07:42.175 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA186 d:FF r:FFBB m:C8 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.184 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C8 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.322 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA219 d:FF r:FFBF m:C9 A010 3F2E6A 1A2B3C 033D204520452045204520452045204520
2019.04.16 16:07:42.332 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: C9 A0 10 3F2E6A 1A2B3C 033D204520452045204520452045204520
2019.04.16 16:07:42.332 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: C9 A0 10 3F2E6A 1A2B3C 033D204520452045204520452045204520
2019.04.16 16:07:42.434 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA289 d:FF r:FFBA m:C9 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.440 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: C9 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.581 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA31C d:FF r:FFBF m:CA A010 3F2E6A 1A2B3C 034C452045204520452045204520452045
2019.04.16 16:07:42.592 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: CA A0 10 3F2E6A 1A2B3C 034C452045204520452045204520452045
2019.04.16 16:07:42.593 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: CA A0 10 3F2E6A 1A2B3C 034C452045204520452045204520452045
2019.04.16 16:07:42.659 0: HMLAN_Parse: HM_HMLAN1 R:E314307 stat:0000 t:19FAA36A d:FF r:FFC1 m:AE 8410 314307 000000 0BA4D30A00
2019.04.16 16:07:42.668 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: AE 84 10 314307 000000 0BA4D30A00
2019.04.16 16:07:42.668 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3A msg: AE 84 10 314307 000000 0BA4D30A00
2019.04.16 16:07:42.693 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA38C d:FF r:FFBB m:CA 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.700 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 38 msg: CA 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.796 0: HMLAN_Parse: HM_HMLAN1 R:E31DA8C stat:0000 t:19FAA3F3 d:FF r:FFC2 m:42 8470 31DA8C 000000 00DD27
2019.04.16 16:07:42.804 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: 42 84 70 31DA8C 000000 00DD27
2019.04.16 16:07:42.805 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 44 msg: 42 84 70 31DA8C 000000 00DD27
2019.04.16 16:07:42.840 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA41F d:FF r:FFBF m:CB A010 3F2E6A 1A2B3C 035B204520452045204520452045204520
2019.04.16 16:07:42.848 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: CB A0 10 3F2E6A 1A2B3C 035B204520452045204520452045204520
2019.04.16 16:07:42.849 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: CB A0 10 3F2E6A 1A2B3C 035B204520452045204520452045204520
2019.04.16 16:07:42.951 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA48E d:FF r:FFBA m:CB 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:42.960 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 38 msg: CB 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.098 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA521 d:FF r:FFBF m:CC A010 3F2E6A 1A2B3C 036A452045204520452045204520452045
2019.04.16 16:07:43.108 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: CC A0 10 3F2E6A 1A2B3C 036A452045204520452045204520452045
2019.04.16 16:07:43.108 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: CC A0 10 3F2E6A 1A2B3C 036A452045204520452045204520452045
2019.04.16 16:07:43.210 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA591 d:FF r:FFBA m:CC 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.220 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 38 msg: CC 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.357 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA623 d:FF r:FFBE m:CD A010 3F2E6A 1A2B3C 0379204520452045204520452045204520
2019.04.16 16:07:43.368 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: CD A0 10 3F2E6A 1A2B3C 0379204520452045204520452045204520
2019.04.16 16:07:43.368 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: CD A0 10 3F2E6A 1A2B3C 0379204520452045204520452045204520
2019.04.16 16:07:43.468 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA693 d:FF r:FFBB m:CD 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.476 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: CD 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.615 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA726 d:FF r:FFBE m:CE A010 3F2E6A 1A2B3C 0388452045204520452045204520452045
2019.04.16 16:07:43.649 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: CE A0 10 3F2E6A 1A2B3C 0388452045204520452045204520452045
2019.04.16 16:07:43.650 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: CE A0 10 3F2E6A 1A2B3C 0388452045204520452045204520452045
2019.04.16 16:07:43.727 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA796 d:FF r:FFBA m:CE 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.746 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: CE 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.873 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA828 d:FF r:FFBF m:CF A010 3F2E6A 1A2B3C 0397204520452045204520452045204520
2019.04.16 16:07:43.884 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: CF A0 10 3F2E6A 1A2B3C 0397204520452045204520452045204520
2019.04.16 16:07:43.884 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: CF A0 10 3F2E6A 1A2B3C 0397204520452045204520452045204520
2019.04.16 16:07:43.984 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA898 d:FF r:FFBA m:CF 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:43.992 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: CF 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:44.132 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAA92B d:FF r:FFBE m:D0 A010 3F2E6A 1A2B3C 03A6452045204520452045204520452045
2019.04.16 16:07:44.147 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: D0 A0 10 3F2E6A 1A2B3C 03A6452045204520452045204520452045
2019.04.16 16:07:44.148 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: D0 A0 10 3F2E6A 1A2B3C 03A6452045204520452045204520452045
2019.04.16 16:07:44.243 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAA99B d:FF r:FFBB m:D0 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:44.252 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: D0 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:44.391 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAAA2E d:FF r:FFBF m:D1 A010 3F2E6A 1A2B3C 03B5204520452045204520452045204520
2019.04.16 16:07:44.400 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: D1 A0 10 3F2E6A 1A2B3C 03B5204520452045204520452045204520
2019.04.16 16:07:44.400 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: D1 A0 10 3F2E6A 1A2B3C 03B5204520452045204520452045204520
2019.04.16 16:07:44.502 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAAA9E d:FF r:FFBB m:D1 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:44.512 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: D1 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:44.647 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAAB2E d:FF r:FFBF m:D2 A010 3F2E6A 1A2B3C 03C4452045204520000000000000
2019.04.16 16:07:44.656 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: D2 A0 10 3F2E6A 1A2B3C 03C4452045204520000000000000
2019.04.16 16:07:44.657 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 36 msg: D2 A0 10 3F2E6A 1A2B3C 03C4452045204520000000000000
2019.04.16 16:07:44.790 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: D2 80 02 1A2B3C 3F2E6A 00
2019.04.16 16:07:44.791 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAABA0 d:FF r:FFBB m:D2 8002 1A2B3C 3F2E6A 00
2019.04.16 16:07:44.894 0: HMLAN_Parse: HM_HMLAN1 R:E3F2E6A stat:0000 t:19FAAC26 d:FF r:FFBF m:D3 8010 3F2E6A 1A2B3C 0300
2019.04.16 16:07:44.904 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: D3 80 10 3F2E6A 1A2B3C 0300
2019.04.16 16:07:44.904 0: HMUARTLGW HM_HMLAN2 recv: 01 05 01 00 37 msg: D3 80 10 3F2E6A 1A2B3C 0300
2019.04.16 16:07:47.687 0: HMLAN_Parse: HM_HMLAN1 R:E55F9C6 stat:0000 t:19FAB70F d:FF r:FFD3 m:26 845E 55F9C6 000000 36727204A438332F0910FF
2019.04.16 16:07:47.704 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 26 84 5E 55F9C6 000000 36727204A438332F0910FF
2019.04.16 16:07:47.704 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3E msg: 26 84 5E 55F9C6 000000 36727204A438332F0910FF
2019.04.16 16:07:48.067 0: HMUARTLGW HM_HMLAN2 send: 01 02 00 00 01 msg: 0D B1 12 1A2B3C 45786F
2019.04.16 16:07:48.465 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FABA1A d:FF r:FFBB m:0D B112 1A2B3C 45786F
2019.04.16 16:07:48.470 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 38 msg: 0D B1 12 1A2B3C 45786F
2019.04.16 16:07:48.595 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FABA9C d:FF r:FFBA m:0D 8002 45786F 1A2B3C 00
2019.04.16 16:07:48.597 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0D 80 02 45786F 1A2B3C 00
2019.04.16 16:07:49.141 0: HMLAN_Parse: HM_HMLAN1 R:E36821F stat:0000 t:19FABCBE d:FF r:FFC4 m:3A 8470 36821F 000000 00C836
2019.04.16 16:07:49.148 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2D msg: 3A 84 70 36821F 000000 00C836
2019.04.16 16:07:49.148 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: 3A 84 70 36821F 000000 00C836
2019.04.16 16:07:49.568 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FABE69 d:FF r:FFBA m:0D B112 1A2B3C 45786F
2019.04.16 16:07:49.576 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 38 msg: 0D B1 12 1A2B3C 45786F
2019.04.16 16:07:49.698 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FABEEA d:FF r:FFBA m:0D 8002 45786F 1A2B3C 00
2019.04.16 16:07:49.704 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0D 80 02 45786F 1A2B3C 00
2019.04.16 16:07:50.412 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): K49
2019.04.16 16:07:50.431 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >K49
2019.04.16 16:07:50.695 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAC2D0 d:FF r:FFBB m:0D B112 1A2B3C 45786F
2019.04.16 16:07:50.704 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 0D B1 12 1A2B3C 45786F
2019.04.16 16:07:50.824 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAC351 d:FF r:FFB8 m:0D 8002 45786F 1A2B3C 00
2019.04.16 16:07:50.832 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0D 80 02 45786F 1A2B3C 00
2019.04.16 16:07:51.423 0: HMUARTLGW HM_HMLAN2 recv: 01 0404, state 100
2019.04.16 16:07:51.424 0: HMUARTLGW HM_HMLAN2 can't send due to unknown problem (no response?)
2019.04.16 16:07:51.424 0: HMUARTLGW HM_HMLAN2 send: 01 02 00 00 00 msg: 0E A0 01 1A2B3C 45786F 0203
2019.04.16 16:07:51.456 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 0E A0 01 1A2B3C 45786F 0203
2019.04.16 16:07:51.461 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAC5CE d:FF r:FFBA m:0E A001 1A2B3C 45786F 0203
2019.04.16 16:07:51.593 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAC652 d:FF r:FFB8 m:0E 8010 45786F 1A2B3C 0100000000
2019.04.16 16:07:51.600 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0E 80 10 45786F 1A2B3C 0100000000
2019.04.16 16:07:51.747 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAC6EC d:FF r:FFB9 m:0E A001 1A2B3C 45786F 0203
2019.04.16 16:07:51.756 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 0E A0 01 1A2B3C 45786F 0203
2019.04.16 16:07:51.965 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0E 80 10 45786F 1A2B3C 0100000000
2019.04.16 16:07:51.965 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAC770 d:FF r:FFB9 m:0E 8010 45786F 1A2B3C 0100000000
2019.04.16 16:07:52.046 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAC818 d:FF r:FFBA m:0E A001 1A2B3C 45786F 0203
2019.04.16 16:07:52.051 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 0E A0 01 1A2B3C 45786F 0203
2019.04.16 16:07:52.178 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAC89D d:FF r:FFB9 m:0E 8010 45786F 1A2B3C 0100000000
2019.04.16 16:07:52.187 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0E 80 10 45786F 1A2B3C 0100000000
2019.04.16 16:07:52.335 0: HMUARTLGW HM_HMLAN2 recv: 01 0404, state 100
2019.04.16 16:07:52.336 0: HMUARTLGW HM_HMLAN2 can't send due to unknown problem (no response?)
2019.04.16 16:07:52.336 0: HMUARTLGW HM_HMLAN2 send: 01 02 00 00 00 msg: 0F A0 01 1A2B3C 45786F 02040000000001
2019.04.16 16:07:52.385 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAC96C d:FF r:FFBB m:0F A001 1A2B3C 45786F 02040000000001
2019.04.16 16:07:52.395 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 0F A0 01 1A2B3C 45786F 02040000000001
2019.04.16 16:07:52.513 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAC9EC d:FF r:FFBA m:0F 8010 45786F 1A2B3C 0208000000
2019.04.16 16:07:52.519 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0F 80 10 45786F 1A2B3C 0208000000
2019.04.16 16:07:52.657 0: HMLAN_Parse: HM_HMLAN1 R:E314307 stat:0000 t:19FACA7C d:FF r:FFC1 m:85 8470 314307 000000 00D331
2019.04.16 16:07:52.662 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3B msg: 85 84 70 314307 000000 00D331
2019.04.16 16:07:52.663 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3C msg: 85 84 70 314307 000000 00D331
2019.04.16 16:07:52.688 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 0F A0 01 1A2B3C 45786F 02040000000001
2019.04.16 16:07:52.693 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FACAA0 d:FF r:FFBB m:0F A001 1A2B3C 45786F 02040000000001
2019.04.16 16:07:52.820 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FACB1F d:FF r:FFB9 m:0F 8010 45786F 1A2B3C 0208000000
2019.04.16 16:07:52.828 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0F 80 10 45786F 1A2B3C 0208000000
2019.04.16 16:07:53.009 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FACBDC d:FF r:FFBB m:0F A001 1A2B3C 45786F 02040000000001
2019.04.16 16:07:53.020 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 0F A0 01 1A2B3C 45786F 02040000000001
2019.04.16 16:07:53.137 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FACC5C d:FF r:FFB9 m:0F 8010 45786F 1A2B3C 0208000000
2019.04.16 16:07:53.139 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 0F 80 10 45786F 1A2B3C 0208000000
2019.04.16 16:07:53.267 0: HMUARTLGW HM_HMLAN2 recv: 01 0404, state 100
2019.04.16 16:07:53.268 0: HMUARTLGW HM_HMLAN2 can't send due to unknown problem (no response?)
2019.04.16 16:07:53.268 0: HMUARTLGW HM_HMLAN2 send: 01 02 00 00 00 msg: 10 A0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:53.315 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FACD0E d:FF r:FFBA m:10 A001 1A2B3C 45786F 00040000000007
2019.04.16 16:07:53.323 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 10 A0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:53.453 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FACD98 d:FF r:FFBA m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:53.464 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:53.652 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FACE5F d:FF r:FFB9 m:10 A001 1A2B3C 45786F 00040000000007
2019.04.16 16:07:53.660 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 10 A0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:53.711 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FACE9A d:FF r:FFB8 m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:53.724 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:53.960 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: 10 A0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:54.212 0: HMUARTLGW HM_HMLAN2 recv: 01 0404, state 100
2019.04.16 16:07:54.212 0: HMUARTLGW HM_HMLAN2 can't send due to unknown problem (no response?)
2019.04.16 16:07:54.874 0: HMLAN_Send: HM_HMLAN1 I:K
2019.04.16 16:07:54.877 0: HMLAN_Parse: HM_HMLAN1 V:03C5 sNo:LEQ0384706 d:29A0A6 O:1A2B3C t:19FAD334 IDcnt:0009 L:2 %
2019.04.16 16:07:55.019 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.16 16:07:55.039 0: HMUARTLGW HM_HMLAN2 recv: 00 040220, state 98
2019.04.16 16:07:55.040 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.16 16:07:55.040 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0201
2019.04.16 16:07:55.257 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.16 16:07:55.275 0: HMUARTLGW HM_HMLAN3 recv: 00 040201, state 98
2019.04.16 16:07:55.275 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.16 16:07:55.276 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0184
2019.04.16 16:07:55.454 0: HMUARTLGW HM_HMLAN2 send: 01 02 00 00 01 msg: 10 B0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:55.856 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAD6FC d:FF r:FFB8 m:10 B001 1A2B3C 45786F 00040000000007
2019.04.16 16:07:55.863 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 38 msg: 10 B0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:55.995 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAD787 d:FF r:FFB9 m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:56.007 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:56.254 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAD88A d:FF r:FFB9 m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:56.263 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:56.512 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAD98C d:FF r:FFB9 m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:56.523 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:57.039 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FADB9B d:FF r:FFBA m:10 B001 1A2B3C 45786F 00040000000007
2019.04.16 16:07:57.047 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3A msg: 10 B0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:57.178 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FADC26 d:FF r:FFB9 m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:57.187 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:57.436 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FADD28 d:FF r:FFB9 m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:57.447 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:57.695 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FADE2B d:FF r:FFBA m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:57.703 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:58.180 0: HMLAN_Parse: HM_HMLAN1 R:E1A2B3C stat:0000 t:19FAE010 d:FF r:FFBA m:10 B001 1A2B3C 45786F 00040000000007
2019.04.16 16:07:58.187 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3A msg: 10 B0 01 1A2B3C 45786F 00040000000007
2019.04.16 16:07:58.318 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAE09A d:FF r:FFBA m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:58.327 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:58.576 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAE19C d:FF r:FFBA m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:58.587 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:58.835 0: HMLAN_Parse: HM_HMLAN1 R:E45786F stat:0000 t:19FAE29F d:FF r:FFB9 m:10 A010 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:58.843 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 4A msg: 10 A0 10 45786F 1A2B3C 03012A22093D0000000087300000000104
2019.04.16 16:07:58.907 0: HMUARTLGW HM_HMLAN2 recv: 01 0404, state 100
2019.04.16 16:07:58.908 0: HMUARTLGW HM_HMLAN2 can't send due to unknown problem (no response?)
2019.04.16 16:08:00.432 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): K4a
2019.04.16 16:08:00.451 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >K4a
2019.04.16 16:08:10.021 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.16 16:08:10.043 0: HMUARTLGW HM_HMLAN2 recv: 00 040226, state 98
2019.04.16 16:08:10.043 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.16 16:08:10.043 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0217
2019.04.16 16:08:10.259 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.16 16:08:10.275 0: HMUARTLGW HM_HMLAN3 recv: 00 040201, state 98
2019.04.16 16:08:10.275 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.16 16:08:10.275 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0161
2019.04.16 16:08:10.452 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): K4b
2019.04.16 16:08:10.471 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >K4b
2019.04.16 16:08:12.945 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:19FB19C0 d:FF r:FFBA m:79 8400 6649B3 000000 2800694F45513233303636383610010100
2019.04.16 16:08:12.945 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.16 16:08:12.947 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4476.
2019.04.16 16:08:12.947 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1485.
2019.04.16 16:08:12.947 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1486.
2019.04.16 16:08:12.947 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1530.
2019.04.16 16:08:12.947 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.16 16:08:12.955 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 30 msg: 79 84 00 6649B3 000000 2800694F45513233303636383610010100
2019.04.16 16:08:12.955 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.16 16:08:12.956 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.16 16:08:12.958 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: 79 84 00 6649B3 000000 2800694F45513233303636383610010100
2019.04.16 16:08:12.958 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.16 16:08:12.958 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.16 16:08:19.464 0: HMLAN_Parse: HM_HMLAN1 R:E31FF57 stat:0000 t:19FB333A d:FF r:FFC3 m:98 865A 31FF57 000000 A8D928
2019.04.16 16:08:19.475 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 48 msg: 98 86 5A 31FF57 000000 A8D928
2019.04.16 16:08:19.476 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 44 msg: 98 86 5A 31FF57 000000 A8D928
2019.04.16 16:08:19.874 0: HMLAN_Send: HM_HMLAN1 I:K
2019.04.16 16:08:19.877 0: HMLAN_Parse: HM_HMLAN1 V:03C5 sNo:LEQ0384706 d:29A0A6 O:1A2B3C t:19FB34E2 IDcnt:0009 L:2 %
2019.04.16 16:08:20.471 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): K4c
2019.04.16 16:08:20.491 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >K4c
2019.04.16 16:08:20.928 0: HMLAN_Parse: HM_HMLAN1 R:E301F53 stat:0000 t:19FB38F1 d:FF r:FFB4 m:3F 8610 301F53 000000 0AA4D00A2800
2019.04.16 16:08:20.945 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: 3F 86 10 301F53 000000 0AA4D00A2800
2019.04.16 16:08:20.945 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 36 msg: 3F 86 10 301F53 000000 0AA4D00A2800
Danke, -MN
Hi Martin,
bei mir geht der Regen-Sensor nicht (HM-Sen-RD-O) richtig.
State des channel_01 (Regen-Sensor) ist nicht "dry" or "rain" sondern = oder 100. Gleiches gilt für den channel_02 (Heizung), nicht "on", sondern "100", und "off" ist 0. :-\
Version ist 10_CUL_HM.pm 19184 2019-04-14 17:07:34Z martinp876
Kannst du noch mal schauen?
Ach sorry, wird schon hier erwähnt...: https://forum.fhem.de/index.php/topic,99431.0.html
Habe noch einen update eingestellt. In cul_hm waren ein paar models lowercase.
@morgennebel
Unklar, warum so oft das device definiert wird. Klappt das nicht? Hast Du am Ende das device? Ich werde es einmal testen.... Die Definition darf nur einmal laufen....
Zitat von: martinp876 am 16 April 2019, 20:27:25
Unklar, warum so oft das device definiert wird. Klappt das nicht? Hast Du am Ende das device? Ich werde es einmal testen.... Die Definition darf nur einmal laufen....
Nein, ich finde das neue Device weder in CUL_HM, noch in Unsorted noch in Everything. Es ist nicht da und kann nicht angelernt werden.
Danke, -MN
@martinp876: nach einem Update heute hab ich ein Warning im Log:
2019.04.17 11:55:56 1: PERL WARNING: Use of uninitialized value $peerFriend in split at ./FHEM/10_CUL_HM.pm line 8784.
Versionsinfo:
File Rev Last Change
10_CUL_HM.pm 19199 2019-04-16 18:05:37Z martinp876
fyi
@Morgennebel
hast mal
list HM_6649B3
probiert? nicht das er auf ignore 1 ist, weil dann siehst ihn nie in Fhemweb.
hab auch noch was:
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $model in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 7801.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $st in hash element at ./FHEM/10_CUL_HM.pm line 4090.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $st in hash element at ./FHEM/10_CUL_HM.pm line 4092.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in hash element at ./FHEM/10_CUL_HM.pm line 4093.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4094.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4095.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4096.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $st in hash element at ./FHEM/10_CUL_HM.pm line 4117.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $st in hash element at ./FHEM/10_CUL_HM.pm line 4132.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $st in hash element at ./FHEM/10_CUL_HM.pm line 4134.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in hash element at ./FHEM/10_CUL_HM.pm line 4135.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4136.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4137.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value $md in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4138.
2019.04.17 17:43:22 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/10_CUL_HM.pm line 8730.
Zitat von: fhem-hm-knecht am 17 April 2019, 13:22:08
hast mal list HM_6649B3 probiert? nicht das er auf ignore 1 ist, weil dann siehst ihn nie in Fhemweb.
2019.04.17 19:18:19.585 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.17 19:18:19.595 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem-master.pl line 4476.
2019.04.17 19:18:19.595 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1486.
2019.04.17 19:18:19.595 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in hash element at ./FHEM/10_CUL_HM.pm line 1487.
2019.04.17 19:18:19.595 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1531.
2019.04.17 19:18:19.596 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.17 19:18:19.603 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.17 19:18:19.608 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.17 19:18:19.614 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.17 19:18:19.619 2: CUL_HM Unknown device HM_6649B3 is now defined
2019.04.17 19:18:35.368 1: Error: >< has no TYPE, but following keys: >helper<
list bringt dann:
No device named HM_6649B3 foundDanke, -MN
OT:Zitat von: Helmuth am 14 April 2019, 17:43:21
Ich habe diese Beiträge nach gestrigen Fhem Problemen verfolgt. Ich muss mich erstmal wundern wie scharf da so kritisiert wird.
Hallo @Helmuth
auch ich lese diesen Thread intensiv mit - wie wohl viele hier. Daher kann ich mich über Deinen Beitrag nur wundern: Wo liest Du denn scharfe Kritik? Also ich sehe keine.
Vielleicht liegt es daran und ist ein Missverständnis: Wer einen Fehler bemerkt, kann und
muss ihn melden, sonst wird er ja nicht behoben. Ähnlich eines Bug-Report-Systems muss der Fehler so präzise und exakt wie möglich beschrieben werden. Ohne Schmus, ohne Girlanden und ohne Beiwerk. Das lenkt nur vom Thema ab, verwirrt und vernebelt. Nur präzise Fehlerberichte helfen dem Maintainer, meinem Namensvetter Martin.
Zitat von: Helmuth am 14 April 2019, 17:43:21
Ich denke Fhem hat weniger Bug's als Windows und ist zudem kostenlos, also sollten die Entwickler bedankt werden für Ihre Arbeit, und nur so nebenbei: Wer arbeitet macht Fehler und wer keine macht hat noch nie gearbeitet.
Das wissen alle. Du, Du erzählst hier niemandem Neuigkeiten. Natürlich sind wir alle dankbar. Einerseits ist es nicht erforderlich, gar hinderlich, jeden Beitrag mit einem Kniefall einzuleiten. Andererseits darf man sich über gegebene Hilfe ab und an bedanken.
Und das tue ich jetzt mal in unser aller Namen: Danke @martinp876
@ yersinia: wird erledigt. Gehört zum peerSmart Kommando
@Ralph: welche Version hast du? Die Aktuelle hat in diesen Zeilen nicht den entsprechenden Code. Mache einen Update und versuche noch einmal.
@Morgennebel: Muss ich probieren, das nachzustellen.
ein
define HM_6649B3 CUL_HM 6649B3
klappt manuell ausgeführt?
Hi Martin,
nach Eingabe von
define HM_6649B3 CUL_HM 6649B3
erhalte ich sofort danach:
Internals:
DEF 6649B3
FUUID 5cb9ba26-f33f-4ba1-4093-d9329b9a348a40a7
NAME HM_6649B3
NOTIFYDEV global
NR 10027
STATE ???
TYPE CUL_HM
chanNo 01
READINGS:
helper:
HM_CMDNR 18
mId 0000
peerFriend
peerOpt -:-
regLst
rxType 1
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
tmpl:
Attributes:
subType virtual
Und im Logfile
2019.04.19 14:08:06.464 1: PERL WARNING: Use of uninitialized value $peerFriend in split at ./FHEM/10_CUL_HM.pm line 8784.
2019.04.19 14:09:16.010 1: CUL_HM 6649B3 error: no IO deviced!!! correct it
Dann den Anlernknopf gedrück und das Device verändert sich auf:
Internals:
DEF 6649B3
FUUID 5cb9ba26-f33f-4ba1-4093-d9329b9a348a40a7
HM_HMLAN1_MSGCNT 1
HM_HMLAN1_RAWMSG E6649B3,0000,2901B97C,FF,FFB8,8784006649B30000002800694F45513233303636383610010100
HM_HMLAN1_RSSI -72
HM_HMLAN1_TIME 2019-04-19 14:09:16
HM_HMLAN2_MSGCNT 1
HM_HMLAN2_RAWMSG 050000508784006649B30000002800694F45513233303636383610010100
HM_HMLAN2_RSSI -80
HM_HMLAN2_TIME 2019-04-19 14:09:16
HM_HMLAN3_MSGCNT 1
HM_HMLAN3_RAWMSG 0500002E8784006649B30000002800694F45513233303636383610010100
HM_HMLAN3_RSSI -46
HM_HMLAN3_TIME 2019-04-19 14:09:16
IODev HM_HMLAN1
LASTInputDev HM_HMLAN2
MSGCNT 3
NAME HM_6649B3
NOTIFYDEV global
NR 10027
STATE ???
TYPE CUL_HM
chanNo 01
lastMsg No:87 - t:00 s:6649B3 d:000000 2800694F45513233303636383610010100
protLastRcv 2019-04-19 14:09:16
protRcv 1 last_at:2019-04-19 14:09:16
rssi_at_HM_HMLAN1 cnt:1 min:-72 max:-72 avg:-72 lst:-72
rssi_at_HM_HMLAN2 cnt:1 min:-80 max:-80 avg:-80 lst:-80
rssi_at_HM_HMLAN3 cnt:1 min:-46 max:-46 avg:-46 lst:-46
READINGS:
2019-04-19 14:09:16 D-firmware 2.8
2019-04-19 14:09:16 D-serialNr OEQ2306686
helper:
HM_CMDNR 174
mId 0069
peerFriend
peerOpt v:switch
regLst 1,3p
rxType 1
supp_Pair_Rep 1
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn
nextSend 1555675756.11725
prefIO
rxt 0
vccu
p:
mRssi:
mNo 87
io:
HM_HMLAN1:
-70
-70
HM_HMLAN2:
-80
-80
HM_HMLAN3:
-46
-46
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
vrt 1
rssi:
at_HM_HMLAN1:
avg -72
cnt 1
lst -72
max -72
min -72
at_HM_HMLAN2:
avg -80
cnt 1
lst -80
max -80
min -80
at_HM_HMLAN3:
avg -46
cnt 1
lst -46
max -46
min -46
tmpl:
Attributes:
expert 1_allReg
model HM-LC-SW1PBU-FM
subType switch
webCmd statusRequest:toggle:on:off
Ich hoffe, daß hilft Dir...
Danke, -MN
Hi Martin,
Nachtrag: ich habe in den Aktor IOgrp VCCU:HM_HMLAN1 gesetzt und danach die VCCU in den Anlernmodus (hmPairForSec). Dann lies sich der Aktor anlernen - aber nicht komplett:
Internals:
DEF 6649B3
FUUID 5cb9ba26-f33f-4ba1-4093-d9329b9a348a40a7
HM_HMLAN1_MSGCNT 21
HM_HMLAN1_RAWMSG R36D491EA,0001,2A562389,FF,FFB1,EA80026649B31A2B3C0101C80047
HM_HMLAN1_RSSI -79
HM_HMLAN1_TIME 2019-04-19 20:21:01
HM_HMLAN2_MSGCNT 18
HM_HMLAN2_RAWMSG 0500003BEA80026649B31A2B3C0101C80047
HM_HMLAN2_RSSI -59
HM_HMLAN2_TIME 2019-04-19 20:21:01
HM_HMLAN3_MSGCNT 18
HM_HMLAN3_RAWMSG 0500002DEA80026649B31A2B3C0101C80047
HM_HMLAN3_RSSI -45
HM_HMLAN3_TIME 2019-04-19 20:21:01
IODev HM_HMLAN1
LASTInputDev HM_HMLAN3
MSGCNT 57
NAME HM_6649B3
NOTIFYDEV global
NR 10027
STATE on
TYPE CUL_HM
chanNo 01
lastMsg No:EA - t:02 s:6649B3 d:1A2B3C 0101C80047
protCmdDel 3
protLastRcv 2019-04-19 20:21:01
protRcv 18 last_at:2019-04-19 20:21:01
protResnd 9 last_at:2019-04-19 19:47:10
protResndFail 3 last_at:2019-04-19 19:47:15
protSnd 18 last_at:2019-04-19 20:21:01
protState CMDs_done
rssi_HM_HMLAN1 cnt:9 min:-80 max:-71 avg:-75.33 lst:-71
rssi_at_HM_HMLAN1 cnt:21 min:-80 max:-65 avg:-73.47 lst:-79
rssi_at_HM_HMLAN2 cnt:18 min:-80 max:-57 avg:-60.38 lst:-59
rssi_at_HM_HMLAN3 cnt:18 min:-47 max:-45 avg:-46 lst:-45
Helper:
DBLOG:
state:
DBLOG:
TIME 1555698061.61013
VALUE on
READINGS:
2019-04-19 20:21:01 CommandAccepted yes
2019-04-19 19:49:49 D-firmware 2.8
2019-04-19 19:49:49 D-serialNr OEQ2306686
2019-04-19 19:47:57 R-intKeyVisib set_invisib
2019-04-19 19:47:57 R-pairCentral set_0x1A2B3C
2019-04-19 20:21:01 deviceMsg on (to VCCU)
2019-04-19 20:21:01 level 100
2019-04-19 20:21:01 pct 100
2019-04-19 20:21:01 recentStateType ack
2019-04-19 20:21:01 state on
2019-04-19 20:21:01 timedOn off
helper:
HM_CMDNR 234
cSnd 111A2B3C6649B30201000000,111A2B3C6649B30201C80000
dlvlCmd ++A0111A2B3C6649B30201C80000
mId 0069
peerFriend
peerOpt v:switch
regLst 1,3p
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn
nextSend 1555698061.71186
rxt 0
vccu VCCU
p:
prefIO:
HM_HMLAN1
mRssi:
mNo EA
io:
HM_HMLAN1:
-77
-77
HM_HMLAN2:
-59
-59
HM_HMLAN3:
-45
-45
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
vrt 1
rssi:
HM_HMLAN1:
avg -75.3333333333333
cnt 9
lst -71
max -71
min -80
at_HM_HMLAN1:
avg -73.4761904761905
cnt 21
lst -79
max -65
min -80
at_HM_HMLAN2:
avg -60.3888888888889
cnt 18
lst -59
max -57
min -80
at_HM_HMLAN3:
avg -46
cnt 18
lst -45
max -45
min -47
shadowReg:
RegL_00. 02:01 0A:1A 0B:2B 0C:3C
tmpl:
Attributes:
IODev HM_HMLAN1
IOgrp VCCU:HM_HMLAN1
expert 1_allReg
model HM-LC-SW1PBU-FM
room R_Flur,SYS_HomeMatic
subType switch
webCmd statusRequest:toggle:on:off
Der Aktor läßt sich jetzt trotz R-pairCentral set_0x1A2B3C von FHEM aus ansteuern und schalten...
Aber richtig sieht das immer noch nicht aus :-/
Danke, -MN
Nachtrag 2:
Aus dem Logfile nach einem Reboot:
2019.04.19 20:37:23.702 0: Server started with 449 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:os pid:9399)
2019.04.19 20:37:24.114 1: EseraDigitalInOut (1W_HWR.ECOut_Sw2) - error: ESERA ID not known
2019.04.19 20:37:41.601 2: AttrTemplates: got 82 entries
2019.04.19 20:38:18.321 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:181, rec:180
2019.04.19 20:38:24.124 2: PWMR_SetRoom PW_RoomInekeSZ: set HM_OG.FLUR_SwLinks_FBInekeSchlafzimmer off
2019.04.19 20:39:08.576 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:85, rec:83
2019.04.19 20:39:08.581 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:85, rec:84
2019.04.19 20:39:08.588 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:85, rec:83
2019.04.19 20:39:08.593 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:85, rec:84
2019.04.19 20:39:12.591 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:92
2019.04.19 20:39:12.596 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:93
2019.04.19 20:39:12.600 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:94
2019.04.19 20:39:12.604 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:95
2019.04.19 20:39:12.607 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:96
2019.04.19 20:39:12.611 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:97
2019.04.19 20:39:12.615 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:98
2019.04.19 20:39:12.618 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:99
2019.04.19 20:39:12.626 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:92
2019.04.19 20:39:12.628 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:93
2019.04.19 20:39:12.631 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:94
2019.04.19 20:39:12.633 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:95
2019.04.19 20:39:12.635 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:96
2019.04.19 20:39:12.637 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:97
2019.04.19 20:39:12.639 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:98
2019.04.19 20:39:12.641 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:100, rec:99
2019.04.19 20:39:13.548 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 3447.
2019.04.19 20:39:13.548 1: waiting for: , got:RegisterRead # await msgNo:, rec:100
2019.04.19 20:39:13.556 1: waiting for: , got:RegisterRead # await msgNo:, rec:101
2019.04.19 20:39:16.598 2: CUL_HM HM_EG.GARDERO_Wandthermostat attack:011A2B3C375D5E02040000000001,011A2B3C375D5E00040000000007:11A2B3C375D5E0203
2019.04.19 20:39:16.608 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:120, rec:119
2019.04.19 20:39:16.617 2: CUL_HM HM_EG.GARDERO_Wandthermostat attack:011A2B3C375D5E02040000000001,011A2B3C375D5E00040000000007:11A2B3C375D5E0203
2019.04.19 20:39:16.624 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:120, rec:119
2019.04.19 20:39:18.391 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:121
2019.04.19 20:39:18.400 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:122
2019.04.19 20:39:18.404 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:123
2019.04.19 20:39:18.407 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:124
2019.04.19 20:39:18.412 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:125
2019.04.19 20:39:18.421 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:121
2019.04.19 20:39:18.439 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:122
2019.04.19 20:39:18.442 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:126, rec:123
2019.04.19 20:39:19.394 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:128
2019.04.19 20:39:19.400 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:129
2019.04.19 20:39:19.407 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:124
2019.04.19 20:39:19.412 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:125
2019.04.19 20:39:19.415 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:126
2019.04.19 20:39:19.419 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:127
2019.04.19 20:39:19.422 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:128
2019.04.19 20:39:19.425 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:130, rec:129
2019.04.19 20:39:20.091 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:133, rec:131
2019.04.19 20:39:20.096 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:133, rec:132
2019.04.19 20:39:20.106 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:133, rec:131
2019.04.19 20:39:20.110 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:133, rec:132
2019.04.19 20:39:21.684 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:134
2019.04.19 20:39:21.690 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:135
2019.04.19 20:39:21.696 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:136
2019.04.19 20:39:21.699 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:137
2019.04.19 20:39:21.703 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:138
2019.04.19 20:39:21.713 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:134
2019.04.19 20:39:21.791 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:135
2019.04.19 20:39:21.798 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:136
2019.04.19 20:39:21.802 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:137
2019.04.19 20:39:21.805 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:139, rec:138
2019.04.19 20:39:23.272 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:140
2019.04.19 20:39:23.279 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:141
2019.04.19 20:39:23.284 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:142
2019.04.19 20:39:23.288 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:143
2019.04.19 20:39:23.295 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:139
2019.04.19 20:39:23.299 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:140
2019.04.19 20:39:23.302 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:141
2019.04.19 20:39:23.305 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:142
2019.04.19 20:39:23.309 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:144, rec:143
2019.04.19 20:39:23.478 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:145, rec:144
2019.04.19 20:39:27.381 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:160, rec:158
2019.04.19 20:39:27.388 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:160, rec:159
2019.04.19 20:39:27.396 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:160, rec:158
2019.04.19 20:39:27.400 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:160, rec:159
2019.04.19 20:39:40.684 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:90, rec:88
2019.04.19 20:39:40.691 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:90, rec:89
2019.04.19 20:39:40.698 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:90, rec:88
2019.04.19 20:39:40.702 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:90, rec:89
Gabs vor dem Anlernen des fraglichen Aktors noch nie...
Ciao, -MN
wenn das Steuern klappt ist das Register auch gesetzt. Offenbar kann es nicht (komplett) gelesen werden.
Die Fehlermeldungen beziehen sich auf die Nummern der Messages. FHEM sendet ein Kommando (Abfrage) und wartet auf eine Antwort zu genau dieser Anfrage.
In deinem Fall sendet das Device aber andere Sequenznummern als erwartet.
Kannst du also einmal den Kompletten getConfig sniffen?
Manche Devices machen fehler beim Sequenzing (eQ3 ist nicht perfekt :( )
Hi Martin,
hier ist ein getConfig gesnifft:
2019.04.20 11:56:29.078 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Kb4
2019.04.20 11:56:29.097 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Kb4
2019.04.20 11:56:30.387 0: HMLAN_Parse: HM_HMLAN1 R:E2E1DC0 stat:0000 t:2DAEBDC1 d:FF r:FFB0 m:AB 8610 2E1DC0 000000 0AA4D70F0000
2019.04.20 11:56:30.407 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: AB 86 10 2E1DC0 000000 0AA4D70F0000
2019.04.20 11:56:30.409 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3C msg: AB 86 10 2E1DC0 000000 0AA4D70F0000
2019.04.20 11:56:30.562 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 35 msg: 9F 86 10 38E510 000000 0AA0CF100500
2019.04.20 11:56:30.574 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2C msg: 9F 86 10 38E510 000000 0AA0CF100500
2019.04.20 11:56:30.575 0: HMLAN_Parse: HM_HMLAN1 R:E38E510 stat:0000 t:2DAEBE37 d:FF r:FFC3 m:9F 8610 38E510 000000 0AA0CF100500
2019.04.20 11:56:33.021 0: HMLAN_Send: HM_HMLAN1 S:S3A2D11E6 stat: 00 t:00000000 d:01 r:3A2D11E6 m:D2 A001 1A2B3C 6649B3 00040000000000
2019.04.20 11:56:33.100 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D2 A0 01 1A2B3C 6649B3 00040000000000
2019.04.20 11:56:33.103 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D2 A0 01 1A2B3C 6649B3 00040000000000
2019.04.20 11:56:33.191 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:2DAEC8B5 d:FF r:FFBC m:D2 A010 6649B3 1A2B3C 0202010A1A0B2B0C3C15FF1800
2019.04.20 11:56:33.196 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: D2 A0 10 6649B3 1A2B3C 0202010A1A0B2B0C3C15FF1800
2019.04.20 11:56:33.199 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2E msg: D2 A0 10 6649B3 1A2B3C 0202010A1A0B2B0C3C15FF1800
2019.04.20 11:56:33.302 0: HMLAN_Parse: HM_HMLAN1 R:R3A2D11E6 stat:0001 t:2DAEC8BA d:FF r:FFBC m:D2 A010 6649B3 1A2B3C 0202010A1A0B2B0C3C15FF1800
2019.04.20 11:56:33.317 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D2 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:33.321 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D2 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:33.435 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:2DAEC9AB d:FF r:FFBC m:D3 A010 6649B3 1A2B3C 030000
2019.04.20 11:56:33.528 0: HMLAN_Send: HM_HMLAN1 S:S3A2D138B stat: 00 t:00000000 d:01 r:3A2D138B m:D4 A001 1A2B3C 6649B3 01040000000001
2019.04.20 11:56:33.533 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2D msg: D3 A0 10 6649B3 1A2B3C 030000
2019.04.20 11:56:33.536 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: D3 A0 10 6649B3 1A2B3C 030000
2019.04.20 11:56:33.565 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D3 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:33.568 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D3 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:33.841 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D4 A0 01 1A2B3C 6649B3 01040000000001
2019.04.20 11:56:33.845 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D4 A0 01 1A2B3C 6649B3 01040000000001
2019.04.20 11:56:33.956 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:2DAECBB2 d:FF r:FFBC m:D4 A010 6649B3 1A2B3C 030800
2019.04.20 11:56:33.965 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2E msg: D4 A0 10 6649B3 1A2B3C 030800
2019.04.20 11:56:33.967 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: D4 A0 10 6649B3 1A2B3C 030800
2019.04.20 11:56:34.023 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.20 11:56:34.045 0: HMUARTLGW HM_HMLAN2 recv: 00 040205, state 98
2019.04.20 11:56:34.045 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.20 11:56:34.045 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0211
2019.04.20 11:56:34.074 0: HMLAN_Parse: HM_HMLAN1 R:R3A2D138B stat:0001 t:2DAECBB7 d:FF r:FFBC m:D4 A010 6649B3 1A2B3C 030800
2019.04.20 11:56:34.089 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D4 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:34.092 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D4 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:34.211 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:2DAECCB3 d:FF r:FFBC m:D5 A010 6649B3 1A2B3C 02300657245600
2019.04.20 11:56:34.221 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2E msg: D5 A0 10 6649B3 1A2B3C 02300657245600
2019.04.20 11:56:34.223 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: D5 A0 10 6649B3 1A2B3C 02300657245600
2019.04.20 11:56:34.341 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D5 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:34.345 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D5 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:34.457 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:2DAECDA9 d:FF r:FFBC m:D6 A010 6649B3 1A2B3C 030000
2019.04.20 11:56:34.550 0: HMLAN_Send: HM_HMLAN1 S:S3A2D1787 stat: 00 t:00000000 d:01 r:3A2D1787 m:D7 A001 1A2B3C 6649B3 0103
2019.04.20 11:56:34.553 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2D msg: D6 A0 10 6649B3 1A2B3C 030000
2019.04.20 11:56:34.555 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: D6 A0 10 6649B3 1A2B3C 030000
2019.04.20 11:56:34.589 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D6 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:34.593 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D6 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:34.862 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D7 A0 01 1A2B3C 6649B3 0103
2019.04.20 11:56:34.865 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D7 A0 01 1A2B3C 6649B3 0103
2019.04.20 11:56:34.980 0: HMLAN_Parse: HM_HMLAN1 R:E6649B3 stat:0000 t:2DAECFB2 d:FF r:FFBC m:D7 A010 6649B3 1A2B3C 0100000000
2019.04.20 11:56:34.989 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2D msg: D7 A0 10 6649B3 1A2B3C 0100000000
2019.04.20 11:56:34.991 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 38 msg: D7 A0 10 6649B3 1A2B3C 0100000000
2019.04.20 11:56:35.096 0: HMLAN_Parse: HM_HMLAN1 R:R3A2D1787 stat:0001 t:2DAECFB7 d:FF r:FFBC m:D7 A010 6649B3 1A2B3C 0100000000
2019.04.20 11:56:35.113 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2F msg: D7 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:35.116 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: D7 80 02 1A2B3C 6649B3 00
2019.04.20 11:56:35.547 0: HMLAN_Send: HM_HMLAN1 I:K
2019.04.20 11:56:35.550 0: HMLAN_Parse: HM_HMLAN1 V:03C5 sNo:LEQ0384706 d:29A0A6 O:1A2B3C t:2DAED1F8 IDcnt:000B L:1 %
2019.04.20 11:56:35.718 0: HMLAN_Parse: HM_HMLAN1 R:E35C61D stat:0000 t:2DAED295 d:FF r:FFB6 m:B9 865A 35C61D 000000 A8DD28
2019.04.20 11:56:35.729 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 32 msg: B9 86 5A 35C61D 000000 A8DD28
2019.04.20 11:56:35.732 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3D msg: B9 86 5A 35C61D 000000 A8DD28
2019.04.20 11:56:37.532 0: HMLAN_Parse: HM_HMLAN1 R:E35EB59 stat:0000 t:2DAED9AB d:FF r:FFC0 m:0E 8470 35EB59 000000 00E435
2019.04.20 11:56:37.544 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3F msg: 0E 84 70 35EB59 000000 00E435
2019.04.20 11:56:37.545 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 43 msg: 0E 84 70 35EB59 000000 00E435
2019.04.20 11:56:38.384 0: HMLAN_Parse: HM_HMLAN1 R:E31DA16 stat:0000 t:2DAEDCFF d:FF r:FFC5 m:A9 865A 31DA16 000000 A4D727
2019.04.20 11:56:38.393 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: A9 86 5A 31DA16 000000 A4D727
2019.04.20 11:56:38.395 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 45 msg: A9 86 5A 31DA16 000000 A4D727
2019.04.20 11:56:39.098 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Kb5
2019.04.20 11:56:39.117 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Kb5
2019.04.20 11:56:40.487 0: HMLAN_Parse: HM_HMLAN1 R:E31FF57 stat:0000 t:2DAEE538 d:FF r:FFC5 m:1A 8470 31FF57 000000 00DD28
2019.04.20 11:56:40.499 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 45 msg: 1A 84 70 31FF57 000000 00DD28
2019.04.20 11:56:40.501 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 46 msg: 1A 84 70 31FF57 000000 00DD28
2019.04.20 11:56:41.794 0: HMLAN_Parse: HM_HMLAN1 R:E38E43B stat:0000 t:2DAEEA52 d:FF r:FFC7 m:A0 8610 38E43B 000000 0AA0CF110700
2019.04.20 11:56:41.813 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 24 msg: A0 86 10 38E43B 000000 0AA0CF110700
2019.04.20 11:56:41.815 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 30 msg: A0 86 10 38E43B 000000 0AA0CF110700
2019.04.20 11:56:42.660 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.20 11:56:42.677 0: HMUARTLGW HM_HMLAN3 recv: 00 040202, state 98
2019.04.20 11:56:42.677 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.20 11:56:42.678 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0160
2019.04.20 11:56:45.547 0: HMLAN_Parse: HM_HMLAN1 R:E36821F stat:0000 t:2DAEF8FB d:FF r:FFC7 m:A0 8470 36821F 000000 00CF32
2019.04.20 11:56:45.558 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 2B msg: A0 84 70 36821F 000000 00CF32
2019.04.20 11:56:45.559 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 40 msg: A0 84 70 36821F 000000 00CF32
2019.04.20 11:56:49.027 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.20 11:56:49.053 0: HMUARTLGW HM_HMLAN2 recv: 00 040205, state 98
2019.04.20 11:56:49.054 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.20 11:56:49.054 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0250
2019.04.20 11:56:49.119 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Kb6
2019.04.20 11:56:49.137 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Kb6
2019.04.20 11:56:49.337 0: HMLAN_Parse: HM_HMLAN1 R:E3F2D76 stat:0000 t:2DAF07CB d:FF r:FFCA m:A3 865A 3F2D76 000000 88DF29
2019.04.20 11:56:49.346 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 4A msg: A3 86 5A 3F2D76 000000 88DF29
2019.04.20 11:56:49.352 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: A3 86 5A 3F2D76 000000 88DF29
2019.04.20 11:56:55.719 0: HMLAN_Parse: HM_HMLAN1 R:E35C61D stat:0000 t:2DAF20B9 d:FF r:FFB7 m:B9 8470 35C61D 000000 00DD28
2019.04.20 11:56:55.738 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3D msg: B9 84 70 35C61D 000000 00DD28
2019.04.20 11:56:55.741 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 32 msg: B9 84 70 35C61D 000000 00DD28
2019.04.20 11:56:57.663 0: HMUARTLGW HM_HMLAN3 send: 00 08
2019.04.20 11:56:57.685 0: HMUARTLGW HM_HMLAN3 recv: 00 040202, state 98
2019.04.20 11:56:57.686 0: HMUARTLGW HM_HMLAN3 GetSet Ack: 02, state 98
2019.04.20 11:56:57.686 0: HMUARTLGW HM_HMLAN3 roundtrip delay: 0.0207
2019.04.20 11:56:58.384 0: HMLAN_Parse: HM_HMLAN1 R:E31DA16 stat:0000 t:2DAF2B22 d:FF r:FFC5 m:A9 8470 31DA16 000000 00D727
2019.04.20 11:56:58.396 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 45 msg: A9 84 70 31DA16 000000 00D727
2019.04.20 11:56:58.397 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: A9 84 70 31DA16 000000 00D727
2019.04.20 11:56:58.782 0: HMLAN_Parse: HM_HMLAN1 R:E38F0FF stat:0000 t:2DAF2CB0 d:FF r:FFCA m:A0 8610 38F0FF 000000 0AA0CF100600
2019.04.20 11:56:58.801 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 2F msg: A0 86 10 38F0FF 000000 0AA0CF100600
2019.04.20 11:56:58.803 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 14 msg: A0 86 10 38F0FF 000000 0AA0CF100600
2019.04.20 11:56:59.139 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Kb7
2019.04.20 11:56:59.157 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Kb7
2019.04.20 11:56:59.423 0: HMLAN_Parse: HM_HMLAN1 R:E38E511 stat:0000 t:2DAF2F32 d:FF r:FFA7 m:5D 8610 38E511 000000 0A98C3090000
2019.04.20 11:56:59.441 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 3B msg: 5D 86 10 38E511 000000 0A98C3090000
2019.04.20 11:56:59.443 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 3F msg: 5D 86 10 38E511 000000 0A98C3090000
2019.04.20 11:57:00.547 0: HMLAN_Send: HM_HMLAN1 I:K
2019.04.20 11:57:00.551 0: HMLAN_Parse: HM_HMLAN1 V:03C5 sNo:LEQ0384706 d:29A0A6 O:1A2B3C t:2DAF33A5 IDcnt:000B L:1 %
2019.04.20 11:57:04.031 0: HMUARTLGW HM_HMLAN2 send: 00 08
2019.04.20 11:57:04.053 0: HMUARTLGW HM_HMLAN2 recv: 00 040205, state 98
2019.04.20 11:57:04.053 0: HMUARTLGW HM_HMLAN2 GetSet Ack: 02, state 98
2019.04.20 11:57:04.054 0: HMUARTLGW HM_HMLAN2 roundtrip delay: 0.0214
2019.04.20 11:57:09.158 0: HMUARTLGW HM_HMLAN3:keepAlive send (3): Kb8
2019.04.20 11:57:09.177 0: HMUARTLGW HM_HMLAN3:keepAlive read (4): >Kb8
2019.04.20 11:57:09.336 0: HMLAN_Parse: HM_HMLAN1 R:E3F2D76 stat:0000 t:2DAF55EE d:FF r:FFC9 m:A3 8470 3F2D76 000000 00DF29
2019.04.20 11:57:09.351 0: HMUARTLGW HM_HMLAN3 recv: 01 05 00 00 39 msg: A3 84 70 3F2D76 000000 00DF29
2019.04.20 11:57:09.352 0: HMUARTLGW HM_HMLAN2 recv: 01 05 00 00 4B msg: A3 84 70 3F2D76 000000 00DF29
Danke, -MN
nun, das ist wie im Bilderbuch gelaufen.
Du betreibst offensichtlich 3 IOs. Das könnte das Problem sein - wenn ein IO die message noch sehr verspätet meldet. Mit diesem Deivce hat es nichts zu tun.
Hast du einen Fall in dem die Meldungen kommen und du gesnifft hast? Das ist der Interessante.
Es handelt sich auf sicher um ein Device mit mehr Register. Kannst du dies finden?
Danke, Martin,
da es jetzt funktioniert, ignoriere ich mein ursprüngliches Problem einfach. Wegschauen hilft.
Aber einen habe ich noch: einer der Ultraschall-Entfernungssensoren zum Selbstbauen hier aus dem Forum:
Internals:
DEF 444008
FUUID 5c585d8a-f33f-4ba1-cdce-46947cfb2a0ebc8b
FVERSION 10_CUL_HM.pm:0.191990/2019-04-16
HM_HMLAN1_MSGCNT 430
HM_HMLAN1_RAWMSG E444008,0000,3E9084F3,FF,FFA9,3AA2534440081A2B3C010201BC1D
HM_HMLAN1_RSSI -87
HM_HMLAN1_TIME 2019-04-23 18:36:14
HM_HMLAN2_MSGCNT 436
HM_HMLAN2_RAWMSG 050000383AA2534440081A2B3C010201BC1D
HM_HMLAN2_RSSI -56
HM_HMLAN2_TIME 2019-04-23 18:36:14
HM_HMLAN3_MSGCNT 433
HM_HMLAN3_RAWMSG 0500004F3AA2534440081A2B3C010201BC1D
HM_HMLAN3_RSSI -79
HM_HMLAN3_TIME 2019-04-23 18:36:14
IODev HM_HMLAN2
LASTInputDev HM_HMLAN2
MSGCNT 1299
NAME HM_AUSSEN.Teichhoehe
NOTIFYDEV global
NR 342
NTFY_ORDER 50-HM_AUSSEN.Teichhoehe
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_AUSSEN.Teichhoehe_Values
lastMsg No:3A - t:53 s:444008 d:1A2B3C 010201BC1D
protLastRcv 2019-04-23 18:36:11
protRcv 74 last_at:2019-04-23 18:36:11
rssi_at_HM_HMLAN1 cnt:430 min:-104 max:-75 avg:-81.03 lst:-87
rssi_at_HM_HMLAN2 cnt:436 min:-69 max:-52 avg:-57.84 lst:-56
rssi_at_HM_HMLAN3 cnt:433 min:-79 max:-63 avg:-68.28 lst:-79
READINGS:
2018-08-15 14:53:25 CommandAccepted yes
2018-08-15 14:53:24 D-firmware 0.2
2018-08-15 14:53:24 D-serialNr FHEM444008
2018-08-15 14:46:03 PairedTo 0x1A2B3C
2018-08-15 14:46:03 R-pairCentral 0x1A2B3C
2018-08-15 14:46:03 RegL_00. 0A:1A 0B:2B 0C:3C 00:00
2018-08-15 14:45:43 sabotageAttack_ErrIoAttack cnt 1
2019-02-04 15:52:01 state CMDs_done
helper:
HM_CMDNR 58
mId 0000
peerFriend
peerOpt -:-
regLst 0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
nextSend 1556037374.83878
vccu VCCU
prefIO:
HM_HMLAN2
mRssi:
mNo 3A
io:
HM_HMLAN1:
-87
-87
HM_HMLAN2:
-50
-50
HM_HMLAN3:
-79
-79
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_HM_HMLAN1:
avg -81.0395348837209
cnt 430
lst -87
max -75
min -104
at_HM_HMLAN2:
avg -57.8440366972477
cnt 436
lst -56
max -52
min -69
at_HM_HMLAN3:
avg -68.2886836027714
cnt 433
lst -79
max -63
min -79
tmpl:
Attributes:
IODev HM_HMLAN2
IOgrp VCCU:HM_HMLAN2
expert 2_raw
model ACTIONDETECTOR
room Aussen,SYS_HomeMatic
subType virtual
webCmd getConfig:clear msgEvents
und
Internals:
DEF 44400801
FUUID 5c585d8a-f33f-4ba1-bcf9-5fb657a173aee7f1
FVERSION 10_CUL_HM.pm:0.191990/2019-04-16
NAME HM_AUSSEN.Teichhoehe_Values
NOTIFYDEV global
NR 343
NTFY_ORDER 50-HM_AUSSEN.Teichhoehe_Values
STATE 59.5 3
TYPE CUL_HM
chanNo 01
device HM_AUSSEN.Teichhoehe
READINGS:
2018-08-15 14:53:26 R-eventDlyTime 3600 s
2018-08-15 14:46:04 R-sign off
2019-02-04 15:52:01 batVoltage 3
2019-02-04 15:52:01 distance 59.5
2019-02-04 15:52:01 state 59.5 3
2018-08-15 14:49:16 value1 2
2018-08-15 14:49:16 value2 217
helper:
peerFriend
peerOpt -:-
regLst
expert:
def 1
det 1
raw 0
tpl 0
role:
chn 1
vrt 1
tmpl:
Attributes:
expert 1_allReg
model ACTIONDETECTOR
peerIDs
userattr valuesformat
valuesformat 2:distance:10 1:batVoltage:10
webCmd press short:press long
model = ACTIONDETECTOR - sieht so flasch aus...
Danke, -MN
ModelID "0000" ist der ActionDetector.
Für selbstbau Devices hatten wir einmal vereinbart, die ID auf "F1xx" zu setzen.
Gannst du das ändern lassen? ActionDetector kann ich nicht ändern.
Moinsen, habe gerade mein fhem auf die aktuelle Version hochgezogen. Nach dem fhem Neustart sieht laut Logfile erstmal alles gut aus, keine Fehlermeldungen.
Nun möchte ich meine neuen HM-SEC-SD-2 in meine fhem Umgebung integrieren.
Ich bin wie folgt vorgegangen:
- Virtuellen Teamlead erstellt
- 1. Rauchmelder gepairt
- diesen Rauchmelder umbenannt
- diesen Rauchmelder dem virt. Team hinzugefügt.
Im Logfile sehe ich nun folgende Perl Warnings:
2019.04.26 22:34:45 3: CUL_HM set VCCU hmPairForSec 600
2019.04.26 22:35:10 2: CUL_HM Unknown device HM_5C70D3 is now defined
2019.04.26 22:35:10 2: autocreate: define HM_5C70D3 CUL_HM 5C70D3
2019.04.26 22:35:10 2: autocreate: define FileLog_HM_5C70D3 FileLog ./log/HM_5C70D3-%Y.log HM_5C70D3
2019.04.26 22:35:10 3: Device HM_5C70D3 added to ActionDetector with 099:00 time
2019.04.26 22:35:10 3: CUL_HM pair: HM_5C70D3 smokeDetector, model HM-SEC-SD-2 serialNr
2019.04.26 22:35:16 3: CUL_HM set HM_5C70D3 statusRequest
2019.04.26 22:35:20 3: CUL_HM set HM_5C70D3 getConfig
2019.04.26 22:44:50 2: autocreate: renamed FileLog_HM_5C70D3 to FileLog_OG_Buero_Rauchmelder
2019.04.26 22:48:04 3: CUL_HM set Rauchmelder_Team peerChan 0 OG_Buero_Rauchmelder single set actor
2019.04.26 22:48:05 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4484.
2019.04.26 22:48:05 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4409.
2019.04.26 22:48:05 1: PERL WARNING: Use of uninitialized value $mh{"dstN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1484.
2019.04.26 22:48:08 3: CUL_HM set OG_Buero_Rauchmelder getConfig
Da ich noch nie einen SD2 eingerichtet habe und ich nicht weiß, ob das so nun überhaupt funktionieren wird, wollte ich das hier mal bekannt geben.
Ich mache erstmal weiter.
Viele Grüße Hoppel
Hallo Hoppel118,
Du hast zwar jetzt Infos gepostet, aber entscheidend wäre erstmal (wie immer) ist den der SD2 richtig angelegt und hat das pairing geklappt?
Warum hast Du kein list vom SD2 gepostet?
Die Show mit dem virtuellen Teamlead ist doch die 2. Show. :D
Gruß Otto
Hallo Otto,
mir ging's hier erstmal nur um die Pearl Warnings im Logfile.
Die sehen nicht normal aus. ;)
Der Rest hat anscheinend ohne Probleme geklappt. Die Devices wurden ohne Probleme gepairt. Virtueller Teamlead ist auch angelegt. Da es mitten in der Nacht ist, verzichte ich erstmal auf weitere Tests. ;)
Ich mache dazu ggf. einen eigenen Thread auf.
Danke und Gruß Hoppel
Hallo Otto,
ich habe gestern Abend insgesamt 3 Rauchmelder angelernt. Die Pearl Warnings im Logfile gab es lediglich beim ersten und zweiten Device, beim dritten nicht.
Meine Vorgehensweise war wie folgt:
- Pairing Device 1 "Büro" mit Pearl Warnings
- FHEM Servicer Neustart
- Pairing Device 2 "Wohnbereich" mit Pearl Warnings
- Pairing Device 3 "Essbereich" ohne Pearl Warnings
- FHEM Servicer Neustart
Hier nochmal das list vom 1. Device "Büro":
Internals:
DEF 5C70D3
FUUID 5cc36b7e-f33f-5dcf-a292-b9ae8468b37e5b00
HMUSB2_MSGCNT 3
HMUSB2_RAWMSG E5C70D3,0000,1EE60BDB,FF,FFC5,C5A6105C70D324242406010000
HMUSB2_RSSI -59
HMUSB2_TIME 2019-04-27 13:34:05
HMUSB_MSGCNT 2
HMUSB_RAWMSG E5C70D3,0000,1EE6241D,FF,FFC8,C5A6105C70D324242406010000
HMUSB_RSSI -56
HMUSB_TIME 2019-04-27 13:34:05
IODev HMUSB2
LASTInputDev HMUSB
MSGCNT 5
NAME OG_Buero_Rauchmelder
NOTIFYDEV global
NR 332
NTFY_ORDER 50-OG_Buero_Rauchmelder
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:C5 - t:10 s:5C70D3 d:242424 06010000
protLastRcv 2019-04-27 13:34:05
protRcv 2 last_at:2019-04-27 13:34:05
protSnd 3 last_at:2019-04-27 13:34:05
protSndB 1 last_at:2019-04-27 00:22:34
protState CMDs_done
rssi_HMUSB2 cnt:1 min:-63 max:-63 avg:-63 lst:-63
rssi_at_HMUSB cnt:2 min:-79 max:-56 avg:-67.5 lst:-56
rssi_at_HMUSB2 cnt:3 min:-69 max:-59 avg:-65.66 lst:-59
READINGS:
2019-04-27 00:22:32 Activity alive
2019-04-26 22:35:18 CommandAccepted yes
2019-04-26 22:35:10 D-firmware 1.0
2019-04-26 22:35:10 D-serialNr OEQ0602549
2019-04-26 22:48:09 PairedTo 0x242424
2019-04-26 22:35:21 R-pairCentral 0x242424
2019-04-26 22:48:09 RegL_00. 00:00 02:01 0A:24 0B:24 0C:24 16:00 1F:00
2019-04-26 22:35:18 aesCommToDev ok
2019-04-26 22:35:18 aesKeyNbr 00
2019-04-27 13:34:05 alarmTest ok
2019-04-27 13:34:05 battery ok
2019-04-27 13:34:05 level 0
2019-04-27 13:34:05 recentStateType info
2019-04-26 22:48:09 sdRepeat off
2019-04-27 13:34:05 smokeChamber ok
2019-04-27 13:34:05 state off
helper:
HM_CMDNR 197
cSnd ,012424245C70D3010E
mId 00AA
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5C70D3,00,00,00
nextSend 1556364845.60641
rxt 0
vccu VCCU
p:
5C70D3
00
00
00
prefIO:
HMUSB2
mRssi:
mNo C5
io:
HMUSB:
-56
-56
HMUSB2:
-53
-53
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMUSB2
flg A
ts 1556364845.4968
ack:
HASH(0x55f48f25d088)
C580022424245C70D300
rssi:
HMUSB2:
avg -63
cnt 1
lst -63
max -63
min -63
at_HMUSB:
avg -67.5
cnt 2
lst -56
max -56
min -79
at_HMUSB2:
avg -65.6666666666667
cnt 3
lst -59
max -59
min -69
tmpl:
Attributes:
IODev HMUSB2
IOgrp VCCU:HMUSB2
actCycle 099:00
actStatus alive
alias Büro Rauchmelder
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
genericDeviceType SmokeSensor
group Rauchmelder
homebridgeMapping StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW
icon secur_smoke_detector
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,
room Büro,Homebridge-Homematic,Rauchmelder
serialNr OEQ0602549
subType smokeDetector
webCmd statusRequestHier das list des zweiten Devices "Wohnbereich":
Internals:
DEF 5C70D2
FUUID 5cc38060-f33f-5dcf-a738-99265a67b33a91f4
HMUSB2_MSGCNT 2
HMUSB2_RAWMSG E5C70D2,0000,1EFE1BBC,FF,FFC0,E8A6105C70D224242406010000
HMUSB2_RSSI -64
HMUSB2_TIME 2019-04-27 14:00:22
HMUSB_MSGCNT 3
HMUSB_RAWMSG E5C70D2,0000,1EFE340C,FF,FFC2,E8A6105C70D224242406010000
HMUSB_RSSI -62
HMUSB_TIME 2019-04-27 14:00:22
IODev HMUSB
LASTInputDev HMUSB2
MSGCNT 5
NAME OG_WZ_Wohnbereich_Rauchmelder
NOTIFYDEV global
NR 336
NTFY_ORDER 50-OG_WZ_Wohnbereich_Rauchmelder
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:E8 - t:10 s:5C70D2 d:242424 06010000
protLastRcv 2019-04-27 14:00:22
protRcv 2 last_at:2019-04-27 14:00:22
protResnd 1 last_at:2019-04-27 00:22:41
protSnd 3 last_at:2019-04-27 14:00:22
protSndB 2 last_at:2019-04-27 00:22:41
protState CMDs_done
rssi_HMUSB cnt:1 min:-70 max:-70 avg:-70 lst:-70
rssi_at_HMUSB cnt:3 min:-75 max:-62 avg:-70.66 lst:-62
rssi_at_HMUSB2 cnt:2 min:-65 max:-64 avg:-64.5 lst:-64
READINGS:
2019-04-27 00:22:32 Activity alive
2019-04-27 00:04:25 CommandAccepted yes
2019-04-27 00:04:16 D-firmware 1.0
2019-04-27 00:04:16 D-serialNr OEQ0602550
2019-04-27 00:11:15 PairedTo 0x242424
2019-04-27 00:04:42 R-pairCentral 0x242424
2019-04-27 00:11:15 RegL_00. 00:00 02:01 0A:24 0B:24 0C:24 16:00 1F:00
2019-04-27 00:04:25 aesCommToDev ok
2019-04-27 00:04:24 aesKeyNbr 00
2019-04-27 14:00:22 alarmTest ok
2019-04-27 14:00:22 battery ok
2019-04-27 14:00:22 level 0
2019-04-27 14:00:22 recentStateType info
2019-04-27 00:11:15 sdRepeat off
2019-04-27 14:00:22 smokeChamber ok
2019-04-27 14:00:22 state off
helper:
HM_CMDNR 232
cSnd ,012424245C70D2010E
mId 00AA
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5C70D2,00,00,00
nextSend 1556366422.51911
rxt 0
vccu VCCU
p:
5C70D2
00
00
00
prefIO:
HMUSB
mRssi:
mNo E8
io:
HMUSB:
-58
-58
HMUSB2:
-64
-64
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMUSB
flg A
ts 1556366422.40981
ack:
HASH(0x55f48f21bbe0)
E880022424245C70D200
rssi:
HMUSB:
avg -70
cnt 1
lst -70
max -70
min -70
at_HMUSB:
avg -70.6666666666667
cnt 3
lst -62
max -62
min -75
at_HMUSB2:
avg -64.5
cnt 2
lst -64
max -64
min -65
tmpl:
Attributes:
IODev HMUSB
IOgrp VCCU:HMUSB
actCycle 099:00
actStatus alive
alias Wohnbereich Rauchmelder
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
genericDeviceType SmokeSensor
group Rauchmelder
homebridgeMapping StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW
icon secur_smoke_detector
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,
room Wohnzimmer,Rauchmelder,Homebridge-Homematic
serialNr OEQ0602550
subType smokeDetector
webCmd statusRequestHier das list des dritten Devices "Essbereich":
Internals:
DEF 5C970C
FUUID 5cc382de-f33f-5dcf-c8c8-bbc9f73fdf6a811a
HMUSB2_MSGCNT 3
HMUSB2_RAWMSG E5C970C,0000,1EEBDEF9,FF,FFBE,79A6105C970C24242406010000
HMUSB2_RSSI -66
HMUSB2_TIME 2019-04-27 13:40:27
HMUSB_MSGCNT 2
HMUSB_RAWMSG E5C970C,0000,1EEBF73F,FF,FFB3,79A6105C970C24242406010000
HMUSB_RSSI -77
HMUSB_TIME 2019-04-27 13:40:27
IODev HMUSB2
LASTInputDev HMUSB2
MSGCNT 5
NAME OG_WZ_Essbereich_Rauchmelder
NOTIFYDEV global
NR 340
NTFY_ORDER 50-OG_WZ_Essbereich_Rauchmelder
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:79 - t:10 s:5C970C d:242424 06010000
protCmdDel 1
protLastRcv 2019-04-27 13:40:27
protRcv 2 last_at:2019-04-27 13:40:27
protResnd 1 last_at:2019-04-27 00:22:39
protResndFail 1 last_at:2019-04-27 00:22:44
protSnd 4 last_at:2019-04-27 13:40:27
protSndB 3 last_at:2019-04-27 00:52:56
protState CMDs_done
rssi_HMUSB2 cnt:1 min:-55 max:-55 avg:-55 lst:-55
rssi_at_HMUSB cnt:2 min:-77 max:-63 avg:-70 lst:-77
rssi_at_HMUSB2 cnt:3 min:-66 max:-61 avg:-62.66 lst:-66
READINGS:
2019-04-27 00:22:32 Activity alive
2019-04-27 00:15:03 CommandAccepted yes
2019-04-27 00:14:54 D-firmware 1.0
2019-04-27 00:14:54 D-serialNr OEQ0955378
2019-04-27 00:17:28 PairedTo 0x242424
2019-04-27 00:15:05 R-pairCentral 0x242424
2019-04-27 00:17:28 RegL_00. 00:00 02:01 0A:24 0B:24 0C:24 16:00 1F:00
2019-04-27 00:15:03 aesCommToDev ok
2019-04-27 00:15:02 aesKeyNbr 00
2019-04-27 13:40:27 alarmTest ok
2019-04-27 13:40:27 battery ok
2019-04-27 13:40:27 level 0
2019-04-27 13:40:27 recentStateType info
2019-04-27 00:17:28 sdRepeat off
2019-04-27 13:40:27 smokeChamber ok
2019-04-27 13:40:27 state off
helper:
HM_CMDNR 121
cSnd 012424245C970C010E,012424245C970C010E
mId 00AA
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5C970C,00,00,00
nextSend 1556365227.30675
rxt 0
vccu VCCU
p:
5C970C
00
00
00
prefIO:
HMUSB2
mRssi:
mNo 79
io:
HMUSB:
-77
-77
HMUSB2:
-62
-62
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMUSB
flg A
ts 1556365227.19698
ack:
HASH(0x55f48f266a00)
7980022424245C970C00
rssi:
HMUSB2:
avg -55
cnt 1
lst -55
max -55
min -55
at_HMUSB:
avg -70
cnt 2
lst -77
max -63
min -77
at_HMUSB2:
avg -62.6666666666667
cnt 3
lst -66
max -61
min -66
tmpl:
Attributes:
IODev HMUSB2
IOgrp VCCU:HMUSB2
actCycle 099:00
actStatus alive
alias Essbereich Rauchmelder
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
genericDeviceType SmokeSensor
group Rauchmelder
homebridgeMapping StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW
icon secur_smoke_detector
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,
room Wohnzimmer,Rauchmelder,Homebridge-Homematic
serialNr OEQ0955378
subType smokeDetector
webCmd statusRequestFür mich sieht das soweit erstmal alles gut aus. Seht ihr das auch so?
Hier noch der relevante Teil aus dem Logfile:
2019.04.26 22:34:45 3: CUL_HM set VCCU hmPairForSec 600
2019.04.26 22:35:10 2: CUL_HM Unknown device HM_5C70D3 is now defined
2019.04.26 22:35:10 2: autocreate: define HM_5C70D3 CUL_HM 5C70D3
2019.04.26 22:35:10 2: autocreate: define FileLog_HM_5C70D3 FileLog ./log/HM_5C70D3-%Y.log HM_5C70D3
2019.04.26 22:35:10 3: Device HM_5C70D3 added to ActionDetector with 099:00 time
2019.04.26 22:35:10 3: CUL_HM pair: HM_5C70D3 smokeDetector, model HM-SEC-SD-2 serialNr
2019.04.26 22:35:16 3: CUL_HM set HM_5C70D3 statusRequest
2019.04.26 22:35:20 3: CUL_HM set HM_5C70D3 getConfig
2019.04.26 22:44:50 2: autocreate: renamed FileLog_HM_5C70D3 to FileLog_OG_Buero_Rauchmelder
2019.04.26 22:48:04 3: CUL_HM set Rauchmelder_Team peerChan 0 OG_Buero_Rauchmelder single set actor
2019.04.26 22:48:05 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4484.
2019.04.26 22:48:05 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4409.
2019.04.26 22:48:05 1: PERL WARNING: Use of uninitialized value $mh{"dstN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1484.
2019.04.26 22:48:08 3: CUL_HM set OG_Buero_Rauchmelder getConfig
2019.04.26 22:58:50 3: CUL_HM set OG2_Dachboden_Strom_Server_Sw statusRequest
2019.04.26 23:29:11 3: CUL_HM set OG2_Dachboden_Strom_Server_Sw statusRequest
2019.04.26 23:36:50 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed (peer: 10.11.11.100)
2019.04.26 23:36:51 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed (peer: 10.11.11.100)
2019.04.26 23:48:08 0: Server shutdown
2019.04.26 23:52:51 1: Including fhem.cfg
2019.04.26 23:52:51 3: telnetPort: port 7072 opened
2019.04.26 23:52:51 3: WEB: port 8083 opened
2019.04.26 23:52:51 3: WEBphone: port 8084 opened
2019.04.26 23:52:51 3: WEBtablet: port 8085 opened
2019.04.26 23:52:51 2: eventTypes: loaded 2227 events from ./log/eventTypes.txt
2019.04.26 23:52:51 1: HMLAN_Parse: HMUSB new condition disconnected
2019.04.26 23:52:51 3: Opening HMUSB device 127.0.0.1:1234
2019.04.26 23:52:51 1: HMLAN_Parse: HMUSB new condition init
2019.04.26 23:52:51 3: HMUSB device opened
2019.04.26 23:52:51 1: HMLAN_Parse: HMUSB2 new condition disconnected
2019.04.26 23:52:51 3: Opening HMUSB2 device 127.0.0.1:1235
2019.04.26 23:52:51 1: HMLAN_Parse: HMUSB2 new condition init
2019.04.26 23:52:51 3: HMUSB2 device opened
2019.04.26 23:52:52 3: OG_Badezimmer_Deckenlampe: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_Badezimmer_Strahler: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_Buero_Deckenlampe: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Stehlampe_oben: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Stehlampe_mitte: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Stehlampe_unten: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Deckenlampe_rechts: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Deckenlampe_links: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Strahler_vorn: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Strahler_hinten: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Essbereich_Deckenlampe_links: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Essbereich_Deckenlampe_mitte: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Essbereich_Deckenlampe_rechts: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Essbereich_Boardlampe_links: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_Haus_Beleuchtung: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_Badezimmer_Beleuchtung: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_Buero_Beleuchtung: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Beleuchtung: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Entertainment_Beleuchtung: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Stehlampe: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Deckenlampe: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Wohnbereich_Strahler: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Essbereich_Deckenlampe: I/O device is HUEBridge
2019.04.26 23:52:52 3: OG_WZ_Essbereich_Boardlampe: I/O device is HUEBridge
2019.04.26 23:52:52 3: Roborock: initialized, using Rijndael
2019.04.26 23:52:52 3: UnifiSwitch_Define - executed. 0
2019.04.26 23:52:52 3: UnifiSwitch_Define - Adress: switch_base
2019.04.26 23:52:52 3: UnifiSwitch_Define - executed. 0
2019.04.26 23:52:52 3: UnifiSwitch_Define - Adress: switch_office
2019.04.26 23:52:52 1: Including ./log/fhem.save
2019.04.26 23:52:52 3: Device Aussen_Nord_Sensor added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device Aussen_Sued_Sensor added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG2_Dachboden_Strom_Server added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_Badezimmer_Sensor added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_Badezimmer_Thermostat added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_Buero_Rauchmelder added to ActionDetector with 099:00 time
2019.04.26 23:52:52 3: Device OG_Buero_Thermostat added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_Flur_Thermostat added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_Kueche_Thermostat added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_SZ_Thermostat added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_WZ_Essbereich_Thermostat added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_WZ_Sensor added to ActionDetector with 000:10 time
2019.04.26 23:52:52 3: Device OG_WZ_Wohnbereich_Thermostat added to ActionDetector with 000:10 time
2019.04.26 23:52:53 0: Featurelevel: 5.9
2019.04.26 23:52:53 0: Server started with 145 defined entities (fhem.pl:19259/2019-04-25 perl:5.024001 os:linux user:fhem pid:3551)
2019.04.26 23:52:53 1: HMLAN_Parse: HMUSB2 new condition ok
2019.04.26 23:52:53 1: HMLAN_Parse: HMUSB new condition ok
2019.04.26 23:52:53 3: CUL_HM set OG2_Dachboden_Strom_Server_Sw statusRequest
2019.04.26 23:52:54 3: CUL_HM set OG_Buero_Rauchmelder statusRequest
2019.04.26 23:53:02 2: AttrTemplates: got 82 entries
2019.04.26 23:53:02 3: Roborock: disconnecting
2019.04.26 23:53:02 2: Roborock: connecting
2019.04.26 23:53:02 3: Roborock: initialized
2019.04.27 00:04:11 3: CUL_HM set VCCU hmPairForSec 600
2019.04.27 00:04:16 2: CUL_HM Unknown device HM_5C70D2 is now defined
2019.04.27 00:04:16 2: autocreate: define HM_5C70D2 CUL_HM 5C70D2
2019.04.27 00:04:16 2: autocreate: define FileLog_HM_5C70D2 FileLog ./log/HM_5C70D2-%Y.log HM_5C70D2
2019.04.27 00:04:16 3: Device HM_5C70D2 added to ActionDetector with 099:00 time
2019.04.27 00:04:16 3: CUL_HM pair: HM_5C70D2 smokeDetector, model HM-SEC-SD-2 serialNr
2019.04.27 00:04:22 3: CUL_HM set HM_5C70D2 statusRequest
2019.04.27 00:04:34 3: CUL_HM set HM_5C70D2 getConfig
2019.04.27 00:05:40 1: RMDIR: ./restoreDir/save/2019-02-15
2019.04.27 00:10:54 2: autocreate: renamed FileLog_HM_5C70D2 to FileLog_OG_WZ_Wohnbereich_Rauchmelder
2019.04.27 00:11:10 3: CUL_HM set Rauchmelder_Team peerChan 0 OG_WZ_Wohnbereich_Rauchmelder single set actor
2019.04.27 00:11:11 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4484.
2019.04.27 00:11:11 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4409.
2019.04.27 00:11:11 1: PERL WARNING: Use of uninitialized value $mh{"dstN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1484.
2019.04.27 00:11:14 3: CUL_HM set OG_WZ_Wohnbereich_Rauchmelder getConfig
2019.04.27 00:14:49 3: CUL_HM set VCCU hmPairForSec 600
2019.04.27 00:14:54 2: CUL_HM Unknown device HM_5C970C is now defined
2019.04.27 00:14:54 2: autocreate: define HM_5C970C CUL_HM 5C970C
2019.04.27 00:14:54 2: autocreate: define FileLog_HM_5C970C FileLog ./log/HM_5C970C-%Y.log HM_5C970C
2019.04.27 00:14:54 3: Device HM_5C970C added to ActionDetector with 099:00 time
2019.04.27 00:14:54 3: CUL_HM pair: HM_5C970C smokeDetector, model HM-SEC-SD-2 serialNr
2019.04.27 00:15:00 3: CUL_HM set HM_5C970C statusRequest
2019.04.27 00:15:04 3: CUL_HM set HM_5C970C getConfig
2019.04.27 00:17:15 2: autocreate: renamed FileLog_HM_5C970C to FileLog_OG_WZ_Essbereich_Rauchmelder
2019.04.27 00:17:22 3: CUL_HM set Rauchmelder_Team peerChan 0 OG_WZ_Essbereich_Rauchmelder single set actor
2019.04.27 00:17:26 3: CUL_HM set OG_WZ_Essbereich_Rauchmelder getConfig
2019.04.27 00:20:38 0: Server shutdownBraucht Ihr noch weitere Informationen für die Analyse der Pearl-Warnings?
Ich habe hier noch 3 weitere SD-2 liegen, die konfiguriert werden wollen. Bin zu allen Schandtaten bereit. ;)
Viele Grüße Hoppel
Jetzt brauch ich auch mal Eure Hilfe. Eines meiner drei virtuellen Devices hatte sich auf einen falschen Subtype gesetzt. Ich hab jetzt "modelForce VIRTUAL" benutzt, es kommt aber jetzt "STATE MISSING ACK. Was muss ich noch rückgängig machen?
defmod v_fensterkontakt_bd_dg CUL_HM 443311
attr v_fensterkontakt_bd_dg .mId 00C7
attr v_fensterkontakt_bd_dg IODev HMLAN1
attr v_fensterkontakt_bd_dg actCycle 002:50
attr v_fensterkontakt_bd_dg actStatus unknown
attr v_fensterkontakt_bd_dg autoReadReg 4_reqStatus
attr v_fensterkontakt_bd_dg expert 2_defReg+raw
attr v_fensterkontakt_bd_dg model VIRTUAL
attr v_fensterkontakt_bd_dg modelForce VIRTUAL
attr v_fensterkontakt_bd_dg room CUL_HM
attr v_fensterkontakt_bd_dg subType virtual
attr v_fensterkontakt_bd_dg webCmd press short:press long
setstate v_fensterkontakt_bd_dg MISSING ACK
setstate v_fensterkontakt_bd_dg 2019-05-11 20:02:14 Activity unknown
setstate v_fensterkontakt_bd_dg 2019-05-11 19:45:14 state MISSING ACK
attr v_fensterkontakt_bd_dg autoReadReg 4_reqStatus
würde ich mal auf off stellen bzw löschen, macht ja keinen Sinn
Der Typ und Subtyp vom korrespondierenden Kanal war auch noch verstellt, jetzt geht alles wieder - Danke!
Grüß euch
Ich habe im Jänner (2020) ein Update gemacht und kann zwar meine HM-Geräte normal ansprechen und bekomme auch den Batteriestatus, aber mein Monitoring-Device findet keine Geräte mehr:
state alive:0 dead:0 unkn:0 off:0
Internals:
CHANGED
DEF 000000
FUUID 5e348e77-f33f-4c05-3783-443fed527a5c5bca
NAME mon_hm
NOTIFYDEV global
NR 81
STATE alive:0 dead:0 unkn:0 off:0
TYPE CUL_HM
chanNo 01
READINGS:
2020-02-06 21:26:07 state alive:0 dead:0 unkn:0 off:0
helper:
HM_CMDNR 191
actCycle 600
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
vrt 1
shadowReg:
tmpl:
Attributes:
actAutoTry 1_on
alias Homematic
event-on-change-reading .*
expert 2_full
group Monitoring
model ACTIONDETECTOR
room Main Functions
subType virtual
define mon_hm CUL_HM 000000
setuuid mon_hm 5e348e77-f33f-4c05-3783-443fed527a5c5bca
#attr mon_hm .mId no
attr mon_hm actAutoTry 1_on
attr mon_hm alias Homematic
attr mon_hm event-on-change-reading .*
attr mon_hm expert 2_full
attr mon_hm group Monitoring
attr mon_hm model ACTIONDETECTOR
attr mon_hm room Main Functions
attr mon_hm subType virtual
Gleiches hie:
Internals:
FUUID 5e348e77-f33f-d478-e5d8-83ed4aadf7172370
NAME info_hom
NR 112
NTFY_ORDER 50-info_hom
STATE updated:2020-02-06 21:26:07
TYPE HMinfo
Version 01
READINGS:
2020-02-06 21:26:07 CRI__protocol -
2020-02-06 21:26:07 C_sumDefined entities:43,device:11,channel:34,virtual:1
2020-02-06 21:26:07 ERR__protocol -
2018-05-14 00:35:53 ERR__unreachable 0
2020-02-04 01:03:13 I_actTotal alive:0,dead:0,unkn:0,off:0
2018-05-14 00:35:53 I_autoReadPend 0
2020-02-06 21:26:07 I_rssiMinLevel 59<:1 60>:6 80>:2 99>:0
2018-05-14 00:35:53 I_sum_battery ok:9,
2018-05-14 00:35:53 I_sum_sabotageError off:2,
2020-02-06 21:26:07 W__protocol -
nb:
cnt 0
Attributes:
alias Homematic
group Information
room Main Functions
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
sumStatus battery,sabotageError,powerError,motor
webCmd update:protoEvents short:rssi:peerXref:configCheck:models
define info_hom HMinfo
setuuid info_hom 5e348e77-f33f-d478-e5d8-83ed4aadf7172370
attr info_hom alias Homematic
attr info_hom group Information
attr info_hom room Main Functions
attr info_hom 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 info_hom sumStatus battery,sabotageError,powerError,motor
attr info_hom webCmd update:protoEvents short:rssi:peerXref:configCheck:models
Im Wiki finde ich zwar die hmid (was die tut ist mir klar), aber diese ominöse .mId nicht. Habe mich hier durch ein paar Seiten gewühlt, aber vieles nicht verstanden und auch keine Lösung gesehen/verstanden.
Wäre cool, wenn mir jemand dabei hilft und ich würde auch gerne verstehen wo das Problem liegt, da es quasi plötzlich nach dem Update da war und der Beitrag ja doch ein halbes Jahr alt ist.
Zitatalias Homematic
bei beiden Geräten ?HMinfo/ACTIONDETECTOR
Zitat#attr mon_hm .mId no
wieso macht man sowas?
zeig mal
get hminfo param -dv actCycle model subType
Man kann doch beliebig vielen Geräten einen identischen Alias geben, wenn man es unübersichtlich möchte... :D
Haben die zu überwachenden Geräte noch alle das Attribut actCycle?
Sind alle Module tatsächlich geupdatet (schüttel) worden?
Was genau nochmal ist an .mID unverständlich?
edit: na gut, in Kurzform wie ich das verstanden habe:
Jedes HM-Gerät wird beim Anlegen per Autocreate durch die Konfigurationsmessage mit einer vierstelligen hexadezimalen Model-ID "geliefert", anhand der CUL_HM die im Attribut model gespeichertet Klarschriftinformation hinterlegt und die passenden Register anlegt. Diese Model-ID kann mit dem Attribut modelForce überschrieben werden - etwa weil vereinzelnte Geräte in der Vergangenheit fehlerhafte model-ID geliefert haben und dadurch ein Schaltkanal fehlte (oder zuviel war). Diese "Ansage" hat auch Einfluss auf die verfügbaren Register und Kanäle.
Für einen eventuellen "Rückweg" beim Löschen des modelForce hat FHEM nun als Backup-ID die in .mId gespeicherte Information um welches Gerät es sich ursprünglich handelte. Das Register ist ja auch üblicherweise versteckt (durch den .).
Zitatwieso macht man sowas?
#attr mon_hm .mId no - Sorry, das hatte ich nur testhalber zum Schluss noch probiert, da mir bis jetzt die mID unbekannt war und ich per Try&Error nach einer Lösung gesucht habe.
param done:
param list
entity : actCycle | model | subType |
con00 : 002:50 | HM-SEC-SCO | threeStateSensor
con01 : 002:50 | HM-SEC-SCO | threeStateSensor
ins00 : 001:00 | HM-LC-SW4-BA-PCB | switch
mod00 : 001:00 | HM-SEN-MDIR-WM55 | motionAndBtn
sed00 : 000:10 | HM-CC-RT-DN | thermostat
sed01 : 000:10 | HM-CC-RT-DN | thermostat
smo00 : 099:00 | HM-SEC-SD-2 | smokeDetector
swt07 : 001:00 | HM-LC-SW2PBU-FM | switch
swt08 : 001:00 | HM-LC-SW2PBU-FM | switch
the00 : 000:10 | HM-TC-IT-WM-W-EU | thermostat
the01 : 000:10 | HM-TC-IT-WM-W-EU | thermostat Ja die Geräte haben noch alle das actCycle-attr. Sollten sie nicht?
Danke für den Post mit der mID. Jetzt verstehe ich auch was die tut.
Neues CUL_HM update enthält einen kleinen Fehler. Für den Sensor HM-MOD-EM-8BIT wird das 8-bit Datum nicht mehr übertragen. Es seht nur noch "contact => (to VCCU)".
Gruß HJB