Hey,
ich nutze einen CUL um meine Homematic-Komponenten in FHEM einzubinden und aktuell keine VCCU - ist irgendwie an mir vorbei gegangen und ich hab aktuell keine Zeit das einzurichten (ist das aufwändig?).
ich habe nun aber folgendes Problem mit meinen Homematic Komponenten:
Ich nutze Türkontakte, Hutschienenaktoren, Thermostate und Unterputzlichtschalter.
Speichere ich nun die fhem.cfg nachdem ich was geändert habe, arbeiten alle Homematic-Komponenten sofort wieder korrekt BIS auf die Unterputzlichtschalter (HM-LC-SW1PBU-FM).
Die beiden sagen bis ich sie das nächste mal von Hand schalte einfach nur "no IO device identified".
Ich hänge mal ein "list" davon an:
Internals:
DEF 593EFF
FUUID 5cd0935b-f33f-0d46-e845-6560c1f69135c4d3
IODev
IODevMissing 1
IODevName HMCUL
NAME BadezimmerLicht
NOTIFYDEV global
NR 149
STATE off
TYPE CUL_HM
chanNo 01
peerList self01,self02,
READINGS:
2019-05-29 08:54:31 CommandAccepted yes
2019-05-14 21:13:45 D-firmware 2.8
2019-05-14 21:13:45 D-serialNr OEQ0358859
2019-05-25 22:28:04 PairedTo 0x466900
2019-05-14 21:43:04 R-intKeyVisib invisib
2019-05-14 21:43:04 R-localResDis off
2019-05-14 21:43:04 R-pairCentral 0x466900
2019-05-14 21:43:05 R-powerUpAction off
2019-05-05 16:02:07 R-self01-lgActionType jmpToTarget
2019-05-05 16:02:07 R-self01-lgCtDlyOff geLo
2019-05-05 16:02:07 R-self01-lgCtDlyOn geLo
2019-05-05 16:02:07 R-self01-lgCtOff geLo
2019-05-05 16:02:07 R-self01-lgCtOn geLo
2019-05-05 16:02:07 R-self01-lgCtValHi 100
2019-05-05 16:02:07 R-self01-lgCtValLo 50
2019-05-05 16:02:07 R-self01-lgMultiExec on
2019-05-05 16:02:07 R-self01-lgOffDly 0 s
2019-05-05 16:02:07 R-self01-lgOffTime unused
2019-05-05 16:02:07 R-self01-lgOffTimeMode absolut
2019-05-05 16:02:07 R-self01-lgOnDly 0 s
2019-05-05 16:02:07 R-self01-lgOnTime unused
2019-05-05 16:02:07 R-self01-lgOnTimeMode absolut
2019-05-05 16:02:07 R-self01-lgSwJtDlyOff on
2019-05-05 16:02:07 R-self01-lgSwJtDlyOn on
2019-05-05 16:02:07 R-self01-lgSwJtOff dlyOn
2019-05-05 16:02:07 R-self01-lgSwJtOn on
2019-05-05 16:02:07 R-self01-shActionType jmpToTarget
2019-05-05 16:02:07 R-self01-shCtDlyOff geLo
2019-05-05 16:02:07 R-self01-shCtDlyOn geLo
2019-05-05 16:02:07 R-self01-shCtOff geLo
2019-05-05 16:02:07 R-self01-shCtOn geLo
2019-05-05 16:02:07 R-self01-shCtValHi 100
2019-05-05 16:02:07 R-self01-shCtValLo 50
2019-05-05 16:02:07 R-self01-shMultiExec off
2019-05-05 16:02:07 R-self01-shOffDly 0 s
2019-05-05 16:02:07 R-self01-shOffTime unused
2019-05-05 16:02:07 R-self01-shOffTimeMode absolut
2019-05-05 16:02:07 R-self01-shOnDly 0 s
2019-05-05 16:02:07 R-self01-shOnTime unused
2019-05-05 16:02:07 R-self01-shOnTimeMode absolut
2019-05-05 16:02:07 R-self01-shSwJtDlyOff off
2019-05-05 16:02:07 R-self01-shSwJtDlyOn off
2019-05-05 16:02:07 R-self01-shSwJtOff off
2019-05-05 16:02:07 R-self01-shSwJtOn dlyOff
2019-05-05 16:02:08 R-self02-lgActionType jmpToTarget
2019-05-05 16:02:08 R-self02-lgCtDlyOff geLo
2019-05-05 16:02:08 R-self02-lgCtDlyOn geLo
2019-05-05 16:02:08 R-self02-lgCtOff geLo
2019-05-05 16:02:08 R-self02-lgCtOn geLo
2019-05-05 16:02:08 R-self02-lgCtValHi 100
2019-05-05 16:02:08 R-self02-lgCtValLo 50
2019-05-05 16:02:08 R-self02-lgMultiExec on
2019-05-05 16:02:08 R-self02-lgOffDly 0 s
2019-05-05 16:02:08 R-self02-lgOffTime unused
2019-05-05 16:02:08 R-self02-lgOffTimeMode absolut
2019-05-05 16:02:08 R-self02-lgOnDly 0 s
2019-05-05 16:02:08 R-self02-lgOnTime unused
2019-05-05 16:02:08 R-self02-lgOnTimeMode absolut
2019-05-05 16:02:08 R-self02-lgSwJtDlyOff off
2019-05-05 16:02:08 R-self02-lgSwJtDlyOn off
2019-05-05 16:02:08 R-self02-lgSwJtOff off
2019-05-05 16:02:08 R-self02-lgSwJtOn dlyOff
2019-05-05 16:02:08 R-self02-shActionType jmpToTarget
2019-05-05 16:02:08 R-self02-shCtDlyOff geLo
2019-05-05 16:02:08 R-self02-shCtDlyOn geLo
2019-05-05 16:02:08 R-self02-shCtOff geLo
2019-05-05 16:02:08 R-self02-shCtOn geLo
2019-05-05 16:02:08 R-self02-shCtValHi 100
2019-05-05 16:02:08 R-self02-shCtValLo 50
2019-05-05 16:02:08 R-self02-shMultiExec off
2019-05-05 16:02:08 R-self02-shOffDly 0 s
2019-05-05 16:02:08 R-self02-shOffTime unused
2019-05-05 16:02:08 R-self02-shOffTimeMode absolut
2019-05-05 16:02:08 R-self02-shOnDly 0 s
2019-05-05 16:02:08 R-self02-shOnTime unused
2019-05-05 16:02:08 R-self02-shOnTimeMode absolut
2019-05-05 16:02:08 R-self02-shSwJtDlyOff on
2019-05-05 16:02:08 R-self02-shSwJtDlyOn on
2019-05-05 16:02:08 R-self02-shSwJtOff dlyOn
2019-05-05 16:02:08 R-self02-shSwJtOn on
2019-05-05 16:02:06 R-sign off
2019-05-14 21:43:05 R-statusInfoMinDly 2 s
2019-05-14 21:43:05 R-statusInfoRandom 1 s
2019-05-14 21:43:05 R-transmitTryMax 6
2019-05-29 08:54:31 deviceMsg off (to HMCUL)
2019-05-29 08:54:31 level 0
2019-05-29 08:54:31 pct 0
2019-05-29 16:22:44 peerList self01,self02,
2019-05-29 08:54:31 recentStateType ack
2019-05-29 08:54:31 state off
2019-05-29 08:54:31 timedOn off
helper:
HM_CMDNR 80
mId 0069
peerFriend peerSens,peerVirt
peerOpt 3:switch
regLst 0,1,3p
rxType 1
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn +593EFF,00,00,00
prefIO
rxt 0
vccu
p:
593EFF
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat 00
role:
chn 1
dev 1
prs 1
Attributes:
IODev HMCUL
alias Licht
autoReadReg 4_reqStatus
expert 1
firmware 2.8
genericDeviceType light
group Licht
model HM-LC-SW1PBU-FM
peerIDs 00000000,593EFF01,593EFF02,
room HomeKit02,Badezimmer,Alexa
serialNr OEQ0358859
sortby 1
subType switch
userattr room_map structexclude
webCmd statusRequest:toggle:on:off
Kann mir jemand dazu helfen? :( Ist ziemlich nervig immer herzulaufen und die beiden einmal zu schalten wenn man die fhem.cfg gespeichert hat.
Vielen Dank und viele Grüße
Patrick
stehen die beiden Kameraden vllt. vor dem define HMCUL in deiner fhem.cfg ?
Bist du auf dem letzten Versionsstand?
Insbesondere, was fhem.pl und DevIO.pm (?) angeht.
editierst du in der fhem.cfg wärend fhem läuft?
Hey, danke für eure Ideen! :)
Zitat von: Wzut am 29 Mai 2019, 16:43:08
stehen die beiden Kameraden vllt. vor dem define HMCUL in deiner fhem.cfg ?
Standen sie tatsächlich... ich habe es mal geändert und auf den ersten Versuch scheint es zu funktionieren! Das wäre ja verrückt!
Version ist up to date, ja. :)
Und ja, ich editiere darin während es läuft. Wieso?
Zitat von: Pati_Alpha am 02 Juni 2019, 17:45:54
Und ja, ich editiere darin während es läuft. Wieso?
Weil es (fast) keinen Grund gibt, fhem.cfg zu editieren. Das ist sogar abgeraten und deswegen ist diese Möglichkeit in Fhem standardmässig deaktiviert.
Achso, das meinst du.
Was tut FHEM denn wenn ich auf normale weise etwas bearbeite und dann auf save config klicke?
Gibts eigentlich eine Möglichkeit, mit z.B. einem DOIF oder so eine Aktion auszuführen sobald die fhem.cfg gespeichert wird?
Zitat von: Pati_Alpha am 03 Juni 2019, 17:04:31
Was tut FHEM denn wenn ich auf normale weise etwas bearbeite und dann auf save config klicke?
Es schreibt die (vorab bei der Eingabe auf Konsistenz geprüfte!) Konifguration weg - also typischerweise in fhem.cfg oder configDB. Ggf. werden dabei anderweitig erfolgte lokale Änderungen auch wieder überschrieben.
ZitatGibts eigentlich eine Möglichkeit, mit z.B. einem DOIF oder so eine Aktion auszuführen sobald die fhem.cfg gespeichert wird?
Schau mal in den Event-Monitor beim Speichern - da gibt es dann auch die Option, direkt einen passenden Eventhandler (notify, DOIF...) anzulegen, Details im Wiki...
Eine Wiki Seite zu den Nachteilen des direkt editierens wäre manchmal nicht schlecht. [emoji23][emoji23][emoji23]
Gesendet von meinem Telekom Puls mit Tapatalk
Zitat von: Frank_Huber am 03 Juni 2019, 18:19:21
Eine Wiki Seite zu den Nachteilen des direkt editierens wäre manchmal nicht schlecht. (https://emoji.tapatalk-cdn.com/emoji23.png)(https://emoji.tapatalk-cdn.com/emoji23.png)(https://emoji.tapatalk-cdn.com/emoji23.png)
feel free... :P
Ja ich muss mir mal endlich nen Zugang beschaffen [emoji6]
Mal schauen ob ich vor dem Urlaub noch was hinbekomme.
Sind ab Samstag 2 Wochen in Ägypten.
Gesendet von meinem Doogee S60 mit Tapatalk
Warum eine Wiki Seite? Diejenige, die fhem.cfg direkt und bedenklos editieren (am besten über Copy/Paste mit einem Windows Editor unter charset iso-8859) sind idR auch die gleiche, die die Doku (CommandRef und Wiki) nicht lesen...
Ja aber dann kann man bei so einem Hilferuf wie hier einfach den Link antworten und der Fall ist erledigt. [emoji6]
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Pati_Alpha am 03 Juni 2019, 17:04:31
Was tut FHEM denn wenn ich auf normale weise etwas bearbeite und dann auf save config klicke?
Z.B. sorgt er dafür, dass das Problem am Anfang dieses Threads nicht passiert!
in der art? 8)
Für solche Fälle hätte ich einen anderen Lösungsansatz: in solchen Threads nicht mehr antworten, bis der Fragesteller selbst darauf kommt, welche Schandtat zu seinem Problem geführt hat und dass er somit selbst schuld an seiner Misere ist. Mutwillig bzw. vorsätzlich.
Zitat von: amenomade am 03 Juni 2019, 19:11:53
Z.B. sorgt er dafür, dass das Problem am Anfang dieses Threads nicht passiert!
Ich bin mir nicht sicher, ob die FHEM-internen Mechanismen das wirklich verhindert hätten. "Sowas" kommt (zumindest in der fhem.cfg-Welt) uU. auch zustande, wenn man ein IO löscht und dann ein anderes anlegt (ob das sinnvoll ist, ist eine andere Frage, aber (ohne VCCU) z.B. nicht zu ändern, wenn man den Typ des IOs für CUL_HM ändert (CUL zu HMUARTLGW)).
Daher ist sowas tatsächlich der einzige Fall, in dem ausnahmsweise cfg-Editieren sogar sinnvoll sein kann (ich habe mangels eigenem Bedarf aber nicht in der cref geschaut, ob es einen Befehl gibt, um IO-Devices "vor" die Clients zu bringen; was es gab, war eine Aktion, um zweistufige Module so umzubauen, dass die Reihenfolge (weitgehend?) egal ist/wurde... Hindert aber niemanden/keinen Modulautor daran, das wieder "falsch" zu machen.)
Zitat von: Beta-User am 04 Juni 2019, 07:48:01
Ich bin mir nicht sicher, ob die FHEM-internen Mechanismen das wirklich verhindert hätten. "Sowas" kommt (zumindest in der fhem.cfg-Welt) uU. auch zustande, wenn man ein IO löscht und dann ein anderes anlegt (ob das sinnvoll ist, ist eine andere Frage, aber (ohne VCCU) z.B. nicht zu ändern, wenn man den Typ des IOs für CUL_HM ändert (CUL zu HMUARTLGW)).
Daher ist sowas tatsächlich der einzige Fall, in dem ausnahmsweise cfg-Editieren sogar sinnvoll sein kann (ich habe mangels eigenem Bedarf aber nicht in der cref geschaut, ob es einen Befehl gibt, um IO-Devices "vor" die Clients zu bringen; was es gab, war eine Aktion, um zweistufige Module so umzubauen, dass die Reihenfolge (weitgehend?) egal ist/wurde... Hindert aber niemanden/keinen Modulautor daran, das wieder "falsch" zu machen.)
Ich wollte es grade sagen. Vielen Dank für die Blumen, aber ich glaube nicht, dass FHEM schlau genug wäre, diese Reihenfolge immer automatisch einzuhalten.
Davon ab nutze ich das Konzept jetzt seit 2,5 Jahren und dies war das erste Mal, dass ich ein Problem damit bekomme.
Und im Übrigen ist dieses Problem ja auch aus coding-sicht nicht gerade intuitiv. Oder meint ihr z.B. ein Java-Entwickler achtet beim Aufsetzen seines Codes darauf, in welcher Reihenfolge die Funktionen im Code stehen? :o ;D
Zitat von: Pati_Alpha am 04 Juni 2019, 13:37:26
Und im Übrigen ist dieses Problem ja auch aus coding-sicht nicht gerade intuitiv. Oder meint ihr z.B. ein Java-Entwickler achtet beim Aufsetzen seines Codes darauf, in welcher Reihenfolge die Funktionen im Code stehen? :o ;D
Entweder das oder er deklariert die Funktion entsprechend. Ansonsten gibt es auch Fehlermeldung.
Zitat von: Pati_Alpha am 04 Juni 2019, 13:37:26
aber ich glaube nicht, dass FHEM schlau genug wäre, diese Reihenfolge immer automatisch einzuhalten.
FHEM ist so schlau, wie "man" es macht (evtl. müßte Martin oder Rudi da nochmal drüber (wg. letzterem die Frage, welche Version von DevIO im Einsatz ist); ich sehe kein grundsätzliches Problem, ggf. entsprechende Routinen zu schaffen, die beim Anlegen oder Ändern die notwendigen Randarbeiten an einer Textfile zu machen. Die andere Frage wäre, ob sich der Aufwand lohnt, und das sehe ich - bis auf wenige Ausnahmen - bisher nicht (fhem.cfg zu editieren ist schließlich nicht verboten, man sollte das nur auf Notfälle beschränken und vorsichtig tun...).
Ansonsten ist aber klar, dass die Reihung der Defines usw. in der cfg in sich logisch geordnet erfolgen sollte, was in der Regel ja automatisch geschieht (ohne IO wird jedenfalls in der Regel kein dazu passendes Client-Device von autocreate erstellt werden...).
Zitat von: Pati_Alpha am 29 Mai 2019, 16:38:30
aktuell keine VCCU - ist irgendwie an mir vorbei gegangen und ich hab aktuell keine Zeit das einzurichten (ist das aufwändig?).
Da du schon dabei bist: eigentlich ist das keine große Sache, kommt aber ggf. auf die Konfiguration deiner Event-Handler an (die HM-Events ändern sich ggf. bzw. es werden mehr). Wenn du "sauber" gearbeitet hast, ist das eine Sache von wenigen Minuten, hinterher dann am besten die VCCU direkt hinter die HomeMatic-IO's packen und dann die cfg nie mehr direkt anfassen...
gleiches problem wie hier: https://forum.fhem.de/index.php/topic,100806.msg942561.html#msg942561 ???
rudi hat da ja was eingebaut...!?
Zitat von: Pati_Alpha am 04 Juni 2019, 13:37:26
Oder meint ihr z.B. ein Java-Entwickler achtet beim Aufsetzen seines Codes darauf, in welcher Reihenfolge die Funktionen im Code stehen? :o ;D
da wird einem auch einiges abgenommen. und man muss sich weniger gedanken machen über solche dinge. ob das nun sinnvoll ist....?!
Zitat von: Pati_Alpha am 02 Juni 2019, 17:45:54
Version ist up to date, ja. :)
Kannst du das bitte nochmal für fhem.pl verifizieren?
Die Änderung, die ich in DevIo verortet hatte, ist tatsächlich in fhem.pl zu finden (soll: ab 19458). Wenn das paßt, besteht vermutlich Nacharbeitsbedarf...
@nils_: Danke für's Nachschlagen, das war die Änderung, die gemeint gewesen war.
Hey, ich bin auf FHEM.pl 19265 gewesen!
Jetzt bin ich auf 19686. Mal sehen, was sich so tut.
Nach umsortieren (und Updaten, aber ich glaube das machte nichts mehr aus) trat das Problem nicht mehr auf! Danke für die Tipps!
Zitat von: Pati_Alpha am 04 Juli 2019, 15:06:50
Nach umsortieren (und Updaten, aber ich glaube das machte nichts mehr aus) trat das Problem nicht mehr auf! Danke für die Tipps!
Andersum testen wäre ggf. aufschlußreicher gewesen...
Wie dem auch sei: [gelöst]? (Bitte Thread-Titel anpassen, das kannst du selbst, indem du den ersten Beitrag editierst).