HM Display-Fernbedienung

Begonnen von notavailable, 23 September 2017, 18:28:48

Vorheriges Thema - Nächstes Thema

zenzi123

Tipp 1-3 hab ich natürlich schon mehrmals gesehen, früher mal, als ich mein fhem das erste mal aufsetzte war das noch nicht so, da war standardmäßig die fhem.cfg über web auch editierbar...

Ich hab ja stets im ersten ansatz die peerings über web gesetzt, gelöscht etc.. aber wie ich in der fhem.cfg sehe greift das nicht immer und überall. das löschen der peerings hab ich natürlich vorm umbenennen gemacht.
Die Frage ist also im Grunde, ob ich direkt im jeweiligen Device die HMID des anderen device in einem Register eintragen/setzen oder auch löschen kann.

set <devicename1> peerChan 0 <devicename2> single set actor

ersetzt ja offensichtlich den devicenamen durch die hmid und setzt das entsprechende peering-register in BEIDEN devices. in der fhem.cfg trägt das aber scheinbar nichts, ein daher ergibt sich für mich die Frage - wozu wird das attr <device> peerIDs xxxx in fhem.cfg dann überhaupt eingetragen und von wem und wann?

Fragen über Fragen, aber ich würd's gern ordentlich verstehen..

MadMax-FHEM

Also folgendes:

Die "Wahrheit" (wie Otto schon geschrieben hat) steht in den Registern der ECHTEN GERÄTE!

Fhem liest dann mit getConfig zurück und schreibt das dann in die fhem.cfg


Wenn du also änderst per Peer-Befehl und kein getConfig machst oder nicht wartest bis dies fertig ist, stimmt nat tatsächlicher Zustand und fhem.cfg nicht.

Hminfo stützt sich nat. auf die fhem.cfg sonst müssten ja jedesmal alle Geräte abgefragt werden: dauert und produziert Funklast...

Hmid etc. einfach umeditieren macht mehr kaputt als es hilft!
Weil wenn du den anderen Aktor mit ja noch im Register eingetragenen Peering wieder nutzt wird er auch schalten...
...und er wird sich ja auch unter SEINEM Namen wieder bei fhem melden: Durcheinander!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Otto123

#17
Zitatdas löschen der peerings hab ich natürlich vorm umbenennen gemacht.
Löschen der peerings erfolgt aber nicht durch löschen in der config!
Das erfolgt durch
peerchan ... unset
peerBulk <peerch1,peerch2,...> unset

Und diese erfordert immer eine Datenübertragung!!! Es schreibt im Gerät! Bei den meisten Batteriegeräten muss man die Datenübertragung anstossen (configtaster)! Steht aber alles auch im Wiki.

Deswegen mein 4. Tipp - Hör auf die fhem.cfg zu lesen, es steht alles in der Weboberfläche. Lies lieber in der Doku, im Wiki oder kauf Dir ein gutes Buch ;)

Wozu es in den attributen steht weiß ich auch nicht. Das ist wahrscheinlich ein relikt aus den Anfängen von FHEM. Es steht ja in den Internals als (Teil)Abbild der Register.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

zenzi123

Das Löschen der peerings hab ich natürlich über den Befehl ..peerChan...unset (und nicht die fhem.cfg) gemacht.
Bei den stromnetz-versorgten Aktoren hab ich nach peerings keine explizite Datenübertragung angestoßen.. der Hinweis, dass dies auch etwas dauern kann könnte hier noch ein Thema sein..
Batteriebetriebene Devices peere ich derzeit - außer der Fernbedienung - keine, und an der FB habe ich nach jedem Peering direkt die Übertragung aktiv angestoßen und vollständig abgewartet. (Hat ja zumeist auch funktioniert aber nicht immer).

Ich werd wohl nochmal in Ruhe die nicht funktionierenden Themen angehen und vor allem die get .. Readings der Geräte holen/ansehen..

Otto123

entscheidend ist aus meiner Sicht:
configCheck von hminfo meldet keine Fehler.

Das peering kann man dort auch separat mit peerXref testen.

Wenn Peers in den Internals nicht mit Namen gezeigt (aufgelöst) werden sondern die achstellige ID drin steht, fehlt FHEM zwar der Peer - es muss aber trotzdem nicht falsch sein. Wenn man es als falsch ermittelt kann man die nur mit peerBulk löschen.

Man kann sich die peerList übrigens auch leicht anzeigen lassen:
list TYPE=CUL_HM i:peerList

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

#20
Zitat von: zenzi123 am 12 September 2019, 07:16:21
Hi, vorab erstmal - VIELEN DANK für die detaillierte Info.


set BUTTON20 peerChan 1 rollo01 single set
set BUTTON20 peerChan 2 rollo02 single set
..


Das hab ich gestern gecoded und das funktioniert soweit auch.
Dann wird hier die Kanalnummer offenbar ignoriert - Sinn macht sie ja nur aus dem Gerät.

set BUTTON20 peerChan 0 rollo01 single set
set BUTTON20 peerChan 0 rollo02 single set

hätte den gleichen Effekt gehabt.

Zitat
ABER - Problem dabei - das ist mir gestern dann bewußt geworden - ist, dass alle Rollos "getoggelt" würden. Wenn z.b. bei 5 Rollos vorher 2 runtergefahren waren und vorher 3 rauf, dann würde eine solche Aktion das nur umkehren. Die 2 würden dann rauffahren und die 3 anderen würden runterfahren. Was ich aber will ist alle Rollos in die gleiche Richtung zu steuern.
Auch dafür gibt es Abhilfe. Ich bin gerade in Eile (wie die letzten Tage auch), aber es ist möglich Aktoren so umzuprogrammieren, dass sie je nach Zustand nur auf jeden gerade oder jeden ungeraden toggle (die Events werden ja hochgezählt) reagieren. So könnte im Toggle bspw. nur jeder ungerade hoch- und jeder gerade herunterfahren. Bei unterschiedlichen letzten Kommandos reagieren die so programmierten Events auf den Toggle ggf. nicht (z.B. wenn sie hochfahren sollen und schon oben sind). Wie auch immer: Es reicht zu sehen dass EIN Aktor in die richtige Richtung fährt um zu wissen dass es alle anderen auch so tun.

---
edit: war doch einfach:
shActionType     |     literal        | required |  options:jmpToTarget,toggleToCnt,toggleToCntInv,off
Also in jedem Aktor gibt es für den jeweiligen Peer (bei Dir bspw. BUTTON20) ein Register shActionType, das default auf "jmpToTarget" steht.
Wenn Du alle Aktoren in diesem Register auf "toggleToCnt" setzt, fahren sie immer in die gleiche Richtung.
Gleiches passiert bei "toggleToCntInv".  Jedoch werden dann alle diese Aktoren genau entgegengesetzt zu "toggleToCnt" fahren.

Die Änderungen betreffen nur den speziellen gepeerten Button und machen daher speziell für "globale" Fernbedienungen" mit Einknopfbedienung Sinn.

edit2: Versuch eines Befehls (ersetze <Aktor> durch die Namen deines Rolladenaktors und <Button> durch den Namen der Fernbedienungstaste)
set <Aktor> regSet shActionType toggleToCnt <Button>
---


Zitat
Eine merkwürdige Sache ist mir aufgefallen: An der FB hieß es nach Druck auf den Config-Button erst "Zentrale/Anlernen", nun heißt es plötzlich "Zentrale/Übernehmen" .. führt aber offensichtlich dennoch das anlernen - bzw. eben das peeren der FB mit den jeweiligen Aktoren aus, denn das hat dann geklappt.
Bedeutet das gleiche. Bei "Anlernen" werden peers wohl neu angelegt, mit "Übernehmen" Konfigurationsänderungen (oder das Hinzufügen von Peers) übernommen. Ist völlig egal.

Zitat
Das blinde Peeren, das ich vorher schon mal gemacht hatte hat übrigens nicht geklappt, der Aktor, der offline war, den ich aber ansonsten mit gleicher Vorgehensweise peeren wollte hat über die FB nicht reagiert. Hier hab ich also ein unset gemacht und nochmal neu gepeert, dann ging das auch.
FHEM speichert Konfigurationsbefehle nur begrenzt. Du kannst nie erwarten, dass ein Gerät dass offline ist, einen Konfig-Befehl nach Tagen nachgereicht bekommt.

Zitat
super, vielen Dank für die Info, hab ums verrecken gestern keine Sonderzeichen geschafft und wenn der Text zu lang wurde hat er plötzlich etwas anderes geschrieben (z.b. rallo statt rollo ...)
Ich nehme an text1 = zeile1, text2=zeile2?
Genau so. Es werden genau zwei Strings in dem Befehl erwatet, die keine Leerzeichen enthalten dürfen, deswegen ja der Konstrukt mit \_.

Der Rest wurde wohl schon bearbeitet.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

zenzi123

Danke für die Infos, bin leider erst jetzt wieder mal dazu gekommen mich damit zu beschäftigen.

Ich hab einen HM 2-Kanal Switch/Aktor (HM-LC_SW2-FM), an dem hängt an einem Kanal ein TV, am anderen ein Licht.
Der Aktor ist definiert als CUL_HM mit der ID z.b. A00001, hat ein IODev, etc, und es sind 2 weitere devices definiert, ebenfalls als CUL_HM mit ID A0000101 (Device TV) und A0000102 (Device TV_Licht)- was ja offensichtlich die 2 Kanäle des Aktors sind.

Ich hab erstmal das Device TV mit der Fernbedienung gepeert, das funktioniert einwandfrei, ich kann mit der entsprechenden Taste der FB den TV ein- bzw. ausschalten.
Dann hab ich auf dem genau gleichen Weg versucht, einen anderen (unbelegten) Button der Fernbedienung mit dem anderen Device (TV_Licht) zu peeren. Das will ums verrecken nicht funktionieren.
Ich bekomme nach einem neuen Anlernen bzw. Konfig übernehmen an der FB trotzdem keinen weiteren Button aktiv. Ich hab's mehrmals versucht, nach einem Fehlschlag auch mit unset wieder sauber gelöscht und nochmal ganz sauber von vorne.. auch einen anderen Button der FB hab ich versucht - keine Chance.

Dann hab ich's über einen Umweg versucht - einen virtuellen Aktor definiert, hier einen Button Btn1 auf Kanal1 am virt. Aktor und mit notify ..Btn1:set_press.* schalte ich das Device TV_Licht auf on bzw. toggle.
Der virtuelle Aktor-Button Btn1 funktioniert auch, wenn ich ihn aus Fhem aufrufe und tut wie er soll.

Nun hab ich versucht, diesen virtuellen Button Btn1 mit einem Button der FB zu peeren.

set BUTTON11 peerChan 0 virt_Btn1 single set


Auch hier - keine Chance... er zeigt mir an der FB keinen neuen Button wenn ich erneut an Zentrale anlerne bzw. config aktualisiere.

Was mache ich hier noch falsch??

Pfriemler

Zitat von: zenzi123 am 09 Oktober 2019, 07:14:56
Was mache ich hier noch falsch??

Das frage ich mich auch. Ich versuche mal zusammenzufassen:
- die Prozeduren sitzen: peerChan, dann Knopf an der FB drücken, Übernahme starten
- Aktor Sw2-FM ist richtig angelegt, zwei Kanäle, kann aus FHEM schalten
- virtueller Button <-> Kanal 2 funktioniert
Demnach scheint (!) es keine Probleme mit dem Aktor zu geben.
- DisplayFB <-> virt. Button funktioniert NICHT
- DisplayFB <-> Kanal 2 funktioniert NICHT.
Die Fernbedienung kann nicht gepeert werden, weder mit einem virtuellen Button noch mit einem realen Aktor.
- Ein spezielles model-Problem mit dem 2-Kanal-Aktor kann hier nicht vorliegen, da das Koppeln mit einem virt. Button immer funktionieren müsste.

Was ich noch dazu weiß:
- Ein Button ist auf der DisplayFB erst anwähl- und bedienbar, wenn es einen Peer gibt.
- es ist möglich Lücken zu lassen (Button1-3, dann ab Button 11) - die leeren Plätze werden beim Anwählen mit dem Rad übersprungen
Bis hierhin alles richtig und logisch.

unset macht nur Sinn, wenn es peer-Reste gibt, etwa im Aktor. Wenn beide Geräte keinen peer ausweisen, bringt es nichts.


Ich würde folgendes tun, wenn nicht bereits geschehen:
- "set BUTTON11 clear msgEvents". Nicht dass da was den Kanal verstopft und deswegen neuere Befehle nicht abgearbeitet werden können.
- immer nach einem Peer-Versuch: "set BUTTON11 getconfig" - und Übernahme an der FB starten
  jetzt erst ist eine Aussage über erfolgreiche Peers möglich

Probiere außerdem einmal, den virtuellen Button mit dem 2-Kanal-Aktor zu peeren. Du hast ja nur eine Kopplung via Notify beschrieben. Dann führt eine Betätigung des virtuellen Buttons auch ohne Notify zu einer Aktion am Aktor. Aber eigentlich sollte das funktionieren, ist mehr akademisch.

Gibt es eine saubere Übernahme an der FB? in der Regel werden erfolgreiche Prozesse mit grün quittiert, bin gerade nicht sicher wie das die DisplayFB macht. Davon unterscheidet sich das Verhalten, wenn man ohne anstehende Konfigurationsarbeit aus FHEM heraus an der FB den Prozess startet. Das blinkt dann dort etwas länger bis zum Timeout, während eine erfolgreiche Aktion nach wenigen Sekunden beendet ist.

Ende des Lateins.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

zenzi123

Danke, ja, die Zusammenfassung ist genau richtig.

Das mit Set Button clear msgEvents und getconfig werd ich mal checken.

Und ja, wenn ich ein set FB_button peerChan... in Fhem mache und dann an der FB übernehme Startet die Display-FB mit Grüner Schrift, blinkt dann rot (bzw. orange) und abschließend endet sie dann mit grün. wenn nix geändert wurde und ich lerne an, dann blinkt sie länger (ich glaub in grün).. bis zum timeout.

also passieren tut da schon was. ich werd evtl. auch mal einen funktionierenden button unpeeren und neu peeren.. nur um -akademisch- zu testen...
den virt. button mit aktor peeren kann ich auch versuchen..
eigentlich müssts ja sowieso direkt und ohne virt. button gehen.. sehr komisch..

zenzi123

Ich hab mir das gestern nochmal angesehen und hab nochmal sicherheitshalber ein set FB_BtnX peerChan ... unset für ALLE buttons gemacht, die ich an der FB nicht brauchte und die nicht belegt sein SOLLTEN.
nach jedem unset brach angelernt/übernommen etc..
Dann hab ich nochmal versucht den 2. kanal vom switch mit einem button der FB zu peeren.... und plötzlich das unerwartete - ES HAT FUNKTIONIERT!!

Offensichtlich war es tatsächlich so, dass noch irgendein peering "festhing" (obwohl ich in den registern und bei peerCheck nicht unpassendes gesehen hätte) und durch das unset dann gelöst wurde.
Nun konnte ich plötzlich auch ganz einfach einen virtuellen button mit einem FB-button peeren.
das press an der FB hat zwar noch nicht funktioniert, hatte dann aber keine zeit mehr mir das noch anzusehen, das kann wohl nix dramatisches mehr sein...



zenzi123

ok.. leider hab ich doch noch ein weiteres Problem, evtl versteh ich'S noch nicht so ganz..

Ich hab nun also einen virtuellen Button vbtn1.
der ist in fhemweb mit wbcmd press short und press long verfügbar.
Ich hab ein notify für den button vbtn1 eingerichtet
defmod test notify vbtn1:set_press.* {DebianMail("mail@domain.com","text"," ") }
Wenn ich den button über web betätige wird das mail gesendet.

Den Button habe ich mit der Fernbedienung gepeert.
An der Fernbedienung ist der neu gepeerte Kanal nun auch aktiv.

Wenn ich aber den entsprechenden kanal an der Fernbedienung drücke, dann löst der notify nicht aus.
An der Fernbedienung wird die Kanalbezeichnung beim drücken ORANGE, kurz darauf dann ROT - was ja bedeutet, dass er kein OK von fhem retour bekommt.

Ich hab keine rechte Idee, wie ich checken kann, ob die Fernbedienung überhaupt ein notify beim drücken des buttons sendet oder wo hier das Problem liegt.
Ich hab zum test mal das notify so eingerichtet:
defmod test notify vbtn1:* {DebianMail("mail@domain.com","text"," ") }
Idee: er soll bei jeder aktion ein mail auslösen.
Problem ist, dass die fernbedienung offensichtlich ziemlich viel sendet, denn nun werde ich mit diesem mail zugespamt.
hab auch notify vbtn1:Short.* .. versucht.. funktioniert auch nicht..
Wo und wie finde ich raus OB die Fernbedienung was beim drücken sendet und WAS sie da sendet?

:-[


Otto123

#26
Immer wieder im Eventmonitor :)

Aufmachen vbtn1.* als Filter und zuschauen  ::)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

hat der virtuelle Button die FB als peer eingetragen? Dann passiert das ACK (orange-grün) automatisch...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."