Hi zusammen,
ich habe einige HM Lichtschalter im Einsatz. Nun ist es so, dass 2 Lichtschalter als an angezeigt werden obwohl sie aus sind. Die haben aber jahrelang funktioniert.
Vor ein paar Tagen habe ich meine config überprüft und als iogroup bei diesen devices die vccu statt einem dedizierten hmlan eingetragen. Meint ihr daran kann es liegen?
Wie bekomme ich das jetzt am saubersten wieder korrekt hin?
Hab schon probiert die devices auf ignore zu setzen und dann zu schalten, aber leider ohne Erfolg.
Oder habt ihr noch einen anderen Tipp für mich?
List eines betroffenen devices:
Internals:
DEF 554BB6
FUUID 5c5dae99-f33f-d748-4dfb-a4b6e9a5fe5ae759
HMLAN_AZ_MSGCNT 10
HMLAN_AZ_RAWMSG E554BB6,0000,025D9EF9,FF,FFB1,23A410554BB6200DB80601C800
HMLAN_AZ_RSSI -79
HMLAN_AZ_TIME 2021-10-18 10:06:14
IODev hmusb
LASTInputDev hmusb
MSGCNT 24
NAME eg_ku_li
NR 158
NTFY_ORDER 48-eg_ku_li
STATE on
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
hmusb_MSGCNT 14
hmusb_RAWMSG E554BB6,0000,1479DBE3,FF,FFCC,23A410554BB6200DB80601C800
hmusb_RSSI -52
hmusb_TIME 2021-10-18 10:06:14
lastMsg No:23 - t:10 s:554BB6 d:200DB8 0601C800
protLastRcv 2021-10-18 10:06:14
protRcv 10 last_at:2021-10-18 10:06:14
protSnd 13 last_at:2021-10-18 10:06:14
protState CMDs_done
rssi_at_HMLAN_AZ cnt:10 min:-83 max:-73 avg:-77.3 lst:-79
rssi_at_hmusb cnt:14 min:-57 max:-52 avg:-56.57 lst:-52
rssi_hmusb cnt:1 min:-60 max:-60 avg:-60 lst:-60
CL:
Authenticated 0
BUF
FD 138
FW_ID 690
LASTACCESS 1634544453
NAME WEB_192.168.175.140_54516
NR 691
PEER 192.168.175.140
PORT 54516
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-10-18 10:07:15 state Connected
READINGS:
2021-10-18 10:05:45 D-firmware 2.8
2021-10-18 10:05:45 D-serialNr OEQ0030507
2021-10-18 10:06:14 IODev hmusb
2021-10-18 10:05:20 PairedTo 0x200DB8
2021-10-18 10:05:20 R-pairCentral 0x200DB8
2021-10-18 10:05:21 R-powerUpAction off
2021-10-18 10:05:21 R-sign off
2021-10-18 10:05:20 RegL_00. 00:00 02:01 0A:20 0B:0D 0C:B8 15:FF 18:00
2021-10-18 10:05:21 RegL_01. 00:00 08:00 30:06 56:00 57:24
2021-10-18 10:06:22 cfgState ok
2021-10-18 10:06:14 commState CMDs_done
2021-10-18 10:06:14 deviceMsg on (to vccu)
2021-10-18 10:06:14 level 100
2021-10-18 10:06:14 pct 100
2021-10-18 10:06:14 recentStateType info
2021-10-18 10:06:14 state on
2021-10-18 10:06:14 timedOn off
helper:
HM_CMDNR 35
cSnd 01200DB8554BB601040000000001,01200DB8554BB60103
cfgStateUpdt 0
lastMsgTm 1634544374.38763
mId 0069
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1634544157.37379
TmplTs 1634544157.37379
cmdKey 1:1:0::eg_ku_li:0069:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt Rauchmelder_Team,dg_fk_li,dg_gl_mo1,eg_fl_db,eg_fl_mo,eg_fl_moBtn_01,eg_fl_moBtn_02,eg_fl_tk1,eg_ga_rain,eg_gb_fk,eg_ku_fk
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
flgs 0
newChn +554BB6,00,01,00
nextSend 1634544374.5292
rxt 0
vccu vccu
p:
554BB6
00
01
00
prefIO:
mRssi:
mNo 23
io:
HMLAN_AZ:
-79
-79
hmusb:
-46
-46
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
rspWait:
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rpt:
IO HMLAN_AZ
flg A
ts 1634544374.38763
ack:
HASH(0x3a6f2b0)
238002200DB8554BB600
rssi:
at_HMLAN_AZ:
avg -77.3
cnt 10
lst -79
max -73
min -83
at_hmusb:
avg -56.5714285714286
cnt 14
lst -52
max -52
min -57
hmusb:
avg -60
cnt 1
lst -60
max -60
min -60
shadowReg:
tmpl:
Attributes:
IOgrp vccu
alias Küche
autoReadReg 4_reqStatus
event-on-change-reading .*
expert defReg,rawReg
firmware 2.8
model HM-LC-SW1PBU-FM
peerIDs 00000000
room Homekit,CUL_HM,alexa,Küche
serialNr OEQ0030507
subType switch
webCmd statusRequest:toggle:on:off
Danke und Gruß,
Tobi
Auch wenn man Softwareprobleme nicht völlig ausschließen kann (=> https://forum.fhem.de/index.php/topic,123436.0.html (https://forum.fhem.de/index.php/topic,123436.0.html)) klingt das für mich nach einem C26-Problem (ausgetrockneter Kondensator, auch wenn zwei gleichzeitig eher ungewöhnlich sind).
Nehmen die Geräte denn Befehle zuverlässig entgegen?
Bzgl. Software wäre es gut, du würdest verraten, welche Versionen du fährst.
Zitatdass 2 Lichtschalter als an angezeigt werden obwohl sie aus sind
hm..., das list zeigt eindeutig, dass er "on" ist und das wird dir dort auch angezeigt.
STATE on
...
2021-10-18 10:06:14 deviceMsg on (to vccu)
2021-10-18 10:06:14 level 100
2021-10-18 10:06:14 pct 100
2021-10-18 10:06:14 state on
ZitatNehmen die Geräte denn Befehle zuverlässig entgegen?
Das mit den c26 hatte ich auch bei 2-3 aktoren, aber dann reagierten sie wirklich nicht mehr. Die hier resgieren, nur ist state halt immer falsch.
Zitat
Bzgl. Software wäre es gut, du würdest verraten, welche Versionen du fährst.
Habe vor meinem post noch ein Update gefahren, insofern aktuelles fhem mit der neuen cul_hm:
10_CUL_HM.pm 25078 2021-10-16 10:31:26Z martinp876
wenn die aktoren in einer klassischen wechselschaltung installiert sind, ist ein korrekter status abhängig vom 2. schalter.
Zitat von: frank am 18 Oktober 2021, 15:05:57
wenn die aktoren in einer klassischen wechselschaltung installiert sind, ist ein korrekter status abhängig vom 2. schalter.
Das kann ich ausschließen. Der eine ist ein einzelner Schalter und der andere funktioniert ja jahrelang ohne hardwaremäßige Änderungen.
Zitat von: onkel-tobi am 18 Oktober 2021, 11:34:29
Die hier reagieren, nur ist state halt immer falsch.
Heißt was? Sie lassen sich schalten, zeigen aber immer den entgegengesetzten Status?
Und ändert sich der Status, wenn man manuell lokal schaltet?
Zitat von: Pfriemler am 18 Oktober 2021, 18:53:51
Heißt was? Sie lassen sich schalten, zeigen aber immer den entgegengesetzten Status?
korrekt
ZitatUnd ändert sich der Status, wenn man manuell lokal schaltet?
Ja, und das zuverlässig.
Habe mal die alte CUL_HM.pm wieder eingespielt aber auch ohne Erfolg.
Hat noch wer eine Idee? Die Aktoren schalten weiterhin sehr zuverlässig, lokal wie über fhem....
Also der Sw1PBU hat kein bistabiles Relais. Es wird bei on bestromt und fällt bei off ab. Der gemeldete Status kann eigentlich nicht anders als korrekt sein, außer mit dem u.g. Attribut. Manche Schalter kann man in ihrer Wertetabelle umprogrammieren, beim Sw1PBU geht das aber m.W. nicht.
Ich greife trotzdem mal franks Anregung auf:
Zitat von: onkel-tobi am 18 Oktober 2021, 16:46:32
Das kann ich ausschließen. Der eine ist ein einzelner Schalter und der andere funktioniert ja jahrelang ohne hardwaremäßige Änderungen.
Es muss ja nicht ein zweiter Schalter im Spiel sein. Der Aktor hat einen Umschaltkontakt und es haben schon etliche den NC-Kontakt verdrahtet und sich über ein inverses Schaltverhalten gewundert. Wenn Du wirklich ganz sicher ausschließen kannst, dass niemand etwas geändert hat, wundert es schon, aber selbst einem Elektriker würde ich nicht über den Weg trauen dass er das nach einem Abklemmen wieder hinbekommt, vor allem wenn der Aktor danach kopfstehend eingebaut wird. Dann stimmt nämlich die lokale Bedienhaptik wieder, aber der Status ist immer falsch.
Nur so eine Diagnoseidee: Wenn Du den Stromkreis einmal ausschaltest (Sicherung) und nach ein paar Sekunden wieder einschaltest, muss der Aktor aus sein und das Licht darf nicht leuchten. Anderenfalls ist der Schalter falsch verdrahtet. Auch ein on-for-timer sollte das Licht begrenzt einschalten und wieder ausschalten. off-for-timer wird nicht unterstützt.
Einen bei richtiger Beschaltung inversen Meldecharakter erreicht man auch mit dem Attribut "param" und dem Wert "levelInverse". In diesem Fall geht der Aktor bei einem on-for-timer 10 etwa physisch an (Licht leuchtet während fhem off meldet) und schaltet danach physikalisch off (und fhem on). Das ist bei Dir aber auch nicht gelistet.
Soweit meine Testideen, ich bitte um feedback.
hi,
Danke für wure Antworten und Tipps.
Zitat von: Pfriemler am 19 Oktober 2021, 21:53:15
Nur so eine Diagnoseidee: Wenn Du den Stromkreis einmal ausschaltest (Sicherung) und nach ein paar Sekunden wieder einschaltest, muss der Aktor aus sein und das Licht darf nicht leuchten. Anderenfalls ist der Schalter falsch verdrahtet.
Das muss ich mir die Tage ml anschauen. Evtl ist er ja wirklich falsch verdrahtet und ich hatte aber levelinverse in der Vergangenheit konfiguriert. Aktuell kann ich das gar nicht setzen.
Zitat
Auch ein on-for-timer sollte das Licht begrenzt einschalten und wieder ausschalten. off-for-timer wird nicht unterstützt.
Das habe ich eben getestet. Bei beiden Schaltern geht das Licht erst nach angegeben Sekunden an und bleibt dann an. Das würde ja dann echt für falsche Verkabelung sprechen? Ich versteh es nur nicht, weil das jahrelang lief und nichts geändert wurde (außer der config Änderung bezüglich vccu und dem Update von cul_hm).
Gruß,
Tobi
Es kann sein, dass Attribute durch Zwischenversionen verloren gegangen waren...
Fröhliches "Würfeln mit Hashes".... :o :( 8)
Zitat von: Beta-User am 19 Oktober 2021, 23:06:37
Es kann sein, dass Attribute durch Zwischenversionen verloren gegangen waren...
So, dann ist denke ich die Erklärung gefunden und ich muss neu verdrahten.
Habe nach Änderungen via configdb gesucht und ein diff gefunden:
attr eg_ku_li param levelInverse
qed...
Also im Ergebnis eine Verkettung unglücklicher Zufälligkeiten, und doch (auch) ein Softwareproblem.
(Immer wieder lustig, dass man mit configDB dann schnell mal schauen kann, wie das den früher mal war, ohne lange alte Daten zu durchgreppen 8) ).
Zitat von: Beta-User am 19 Oktober 2021, 23:14:41
Also im Ergebnis eine Verkettung unglücklicher Zufälligkeiten, und doch (auch) ein Softwareproblem.
Jep. Ich bin ja nur glücklich, dass jetzt die Ursache geklärt ist. Ich hab mich ja selbst schon für völlig irre gehalten 😂.
Levelinverse scheint insofern komplett zu ,,fehlen" in der aktuellsten Version.
Zitat
(Immer wieder lustig, dass man mit configDB dann schnell mal schauen kann, wie das den früher mal war, ohne lange alte Daten zu durchgreppen 8) ).
Jep, auf die config Dateien hätte ich heute auch keine Lust mehr gehabt...
Hm. lt. commandref gibt es das nur bei "blind" - kann also durchaus sein, dass das gar kein Würfeln war, sondern diese Variante bei anderen Devices nicht mehr zugelassen ist. Inwiefern das ganz genau so beabsichtigt ist, entzieht sich meiner Kenntnis...
("jemand" könnte in den Code schauen, aber nicht mehr heute...)
wenn levelinverse funktioniert und hilft, sollte man es auch freischalten.
aus ökologischer und ökonomischer sicht natürlich völliger unsinn. also unbedingt den anschluss korrigieren.
Zitat von: frank am 20 Oktober 2021, 00:07:33
wenn levelinverse funktioniert und hilft, sollte man es auch freischalten.
aus ökologischer und ökonomischer sicht natürlich völliger unsinn. also unbedingt den anschluss korrigieren.
~#1393:
$hash->{AttrX}{'switch'} = { # subType
param => 'showTimed,levelInverse'
?
Bei Typ Blind ist es aber auch nicht mehr da. Da macht es ja in jd. Fall Sinn.
Welche Version fährst du? Bei der "patch"-Version von gestern abend und einer Stichprobe an HM-LC-BL1PBU-FM wurde diese Option jedenfalls im betreffenden param-Attribut angezeigt. Und auch die aktuelle svn-Version tickt an der Stelle nicht anders (afaik).
Kann aber natürlich sein, dass ich mal wieder was übersehen habe.
$hash->{AttrX}{'switch'} = { # subType
param => 'showTimed,levelInverse'
mit dieser ergänzung ist die option levelInverse zusätzlich zu showTimer dazu gekommen und auch in .AttrList zu sehen.
und es funktioniert wie "befürchtet" bei einem HM-LC-SW1PBU-FM. 8)
...bleibt die Frage, ob es ein bug oder ein feature ist, wenn man "Hardwarefehler" nicht mehr "überstimmen" kann...
(Ich pack's bei Gelegenheit auf die Liste...)
[OT]
- Falls jemand Ideen zu https://forum.fhem.de/index.php/topic,123298.0.html hat: her damit. Testweise hatte ich nach dem freundlichen Hinweis von hier (https://forum.fhem.de/index.php/topic,123208.msg1179943.html#msg1179943) mal ein paar "qq"-Anweisungen im Code verteilt, leider ohne greifbares Ergebnis; möglicherweise hatte ich die richtige Stelle nicht getroffen, vielleicht ist auch der Ansatz falsch.
- Unklar ist mir auch, was sich hinter https://forum.fhem.de/index.php/topic,123514.0.html verbirgt. Habe gestern noch testweise eine party-Anweisung rausgehauen, da erschien zumindest erst mal ein set_... im Reading, danach hatte ich keine Lust mehr...
(Überhaupt: "eigentlich" wollte ich "nur mal kurz" einen Vorschlag für das stateFormat-Problem liefern... :-\ )
der hilfstext beim attribut sieht so aus, "available parameter" ist ein link:
Zitatparam
param defines model specific behavior or functions. See available parameter for details
die link-adresse zeigt an: "http://192.168.1.25:8083/fhem/docs/commandref.html#CUL_HM-attr-params".
wenn ich diesen link zum öfnen in einem neuen tab anklicke, erscheint im neuen tab lediglich eine "verkürzte" commandref anzeige, die die 3 tabellen enthält und unten lediglich die fhem commands.
aber eben keine infos zu cul_hm, wodurch der ankerpunkt zu attr-params natürlich ebenfalls fehlt.
sämtliche links in den 3 tabellen zeigen das selbe und erzeugen immer die selbe seite, also keine chance zum gewünschten text zu gelangen.
hat sicherlich auch mit meiner "modularen" voreinstellung zu tun.
lässt sich der text, den ich eigentlich hinter dem link vermute, vielleicht auch gleich zusätzlich mit anzeigen?
noch besser wäre natürlich nur der entsprechende abschnitt zum jeweiligen device.
Zitatavailable parameter for attribut "param"
HM-SEN-RD-O
offAtPon heat channel only: force heating off after powerOn
onAtRain heat channel only: force heating on while status changes to 'rain' and off when it changes to 'dry'
virtuals
noOnOff virtual entity will not toggle state when trigger is received. If this parameter is not given the entity will toggle its state between On and Off with each trigger
msgReduce:<No> if channel is used for valvePos it skips every No message in order to reduce transmit load. Numbers from 0 (no skip) up to 9 can be given. VD will lose connection with more then 5 skips
blind
levelInverse while HM considers 100% as open and 0% as closed this may not be intuitive to all user. Ny default 100% is open and will be dislayed as 'on'. Setting this param the display will be inverted - 0% will be open and 100% is closed.
NOTE: This will apply to readings and set commands. It does not apply to any register.
ponRestoreSmart upon powerup of the device the Blind will drive to expected closest endposition followed by driving to the pre-PON level
ponRestoreForce upon powerup of the device the Blind will drive to level 0, then to level 100 followed by driving to the pre-PON level
sensRain
siren
powerMeter
switch
dimmer
rgb
showTimed if timmed is running -till will be added to state. This results eventually in state on-till which allowes better icon handling.
--------------
Zitat...bleibt die Frage, ob es ein bug oder ein feature ist, wenn man "Hardwarefehler" nicht mehr "überstimmen" kann...
kann nur ein "versehen" sein, also bug, dass es beim switch nicht vorhanden ist.
letztendlich entscheidet ja eine angeschlossene last darüber, was on oder off bedeutet.
für potentialfreie ausgänge eines aktors gibt es ja auch anwendungsfälle, die zb bei netzausfall, einen geschlossenen kontakt benötigen.
Zitat von: frank am 20 Oktober 2021, 10:01:34
$hash->{AttrX}{'switch'} = { # subType
param => 'showTimed,levelInverse'
mit dieser ergänzung ist die option levelInverse zusätzlich zu showTimer dazu gekommen und auch in .AttrList zu sehen.
und es funktioniert wie "befürchtet" bei einem HM-LC-SW1PBU-FM. 8)
Ich nutze noch
10_CUL_HM.pm 23856 2021-02-28 17:45:41Z martinp876und da hat das Setzen von levelInverse testweise funktioniert. War mir bis dahin neu dass das auch bei switch geht. Ich hatte einfach keine andere Idee mehr für die inverse Meldung, freut mich dass es das wohl (im Zusammenhang mit der zuerst von frank vermuteten Falschverdrahtung) war. Auch unterstreiche ich franks Vorschlag, das alsbald zu korrigieren (also umklemmen des Ausgangs von 1 auf 2 und Drehen des Aktors um 180 Grad), weil jetzt offenbar im off-Zustand das Relais angezogen ist und den Standby des Aktors fast verdoppelt.
edit: Wenn levelInverse auch bei Blinds kaputt ist, bekomme ich ein Problem.
edit2: Ich gehöre wohl langsam zum Urgestein, wenn ich noch config-Dateien benutze? Regelmäßige Snapshots liegen bei mir auf dem Rechner als Backup und mit Totalcommander habe bisher noch jede Installationsleiche in Sekunden gefunden... Ich nutze auch noch MQTT statt MQTT2 ... :o
Zitat von: Pfriemler am 20 Oktober 2021, 11:34:03
Ich nutze noch
Das "Problem" ist erst später (und dann erst mal nach dem Zufallsprinzip) entstanden, und bei "blind" sollte es jetzt auch wieder gefixt sein.
Würde auch empfehlen, das in diesem Fall an der Wurzel anzupacken und die Verdrahtung umzustellen, aber franks Argument ist valide, die CUL_HM im "patches II"-Thread ist daher entsprechend angepaßt und getauscht.
Das mit der commandref zu fixen war etwas aufwändiger, aber jetzt wird der betreffende Abschnitt direkt angezeigt (nicht mehr so schön, was die Gesamtübersicht angeht, aber ich fand es besser, das bei der Attributhilfe komplett anzuzeigen, modellspezifisches Filtern geht leider nicht).
Zitat von: frank am 20 Oktober 2021, 11:57:28
zeile 139 ändern zu:
;D ... demnach war meine Grundannahme falsch, dass das im Zuge der Referenzierungen kaputt gegangen ist und das Problem besteht schon länger, es hat nur noch keiner gemeldet...?!?
Werde mal betateilchen anpingen, was er dazu meint (es sind ja offenkundig sowieso CUL_HM-Sonderlocken drin, und die zwei models könnte man auch bei virtual mit wegfiltern, wird schon nicht so viele Module geben, die diese speziellen keywords verwenden.
Schwieriger ist evtl. das mit chanNo...)
Hi zusammen,
vielen Dank nochmals für eure Unterstützung und Hinweise.
Habe die Verdrahtung nun umgestellt und siehe da: kam macht man es richtig funktionierts :)
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 21 Oktober 2021, 21:29:20
... ka(u)m macht man es richtig funktionierts :)
Mein Reden, siehe Signatur ...