HM-MOD-EM8 TFK Modus peeren mit Schaltaktor HM-LC-SW4-PCB

Begonnen von cracalien, 04 April 2023, 09:13:54

Vorheriges Thema - Nächstes Thema

cracalien

Guten Morgen,

ich scheitere aktuell bei einem Peering und finde einfach den Fehler nicht. Vielleicht kann mich jemand von Euch drauf stupsen was ich übersehe.
Eigentlich dachte ich die Geschichte mit dem Peeren verstanden zu haben ;)

Hintergrund:
Unsere Dunstesse soll über FHEM gesteuert werden können (Abluft bei Feuchtigkeitsproblemen) - Ziel ist es dass die Dunstesse sich weiterhin ohne FHEM normal über das Bedienfeld steuern lässt, aber Ihren Status an FHEM überträgt und sich auch dort steuern lässt.
Dabei habe ich etwas tiefer in die Elektronik eingegriffen. Den jeweiligen gewünschten Schaltzustand vom Bedienfeld ermittele ich mit einem HM-MOD-EM8 im TFK Modus über die Spannungseingänge am EM8. Darüber erkenne ich welche Motorstufe (1-3) geschaltet sein soll oder ob das Licht eingeschaltet sein soll.
Die Verbraucher der Dunsthaube (Motor + Licht) sind mit Hilfe der passenden Relais an ein HM-LC-SW4-PCB angebunden und können darüber in den entsprechenden Schaltzustand gebracht werden.

IST Zustand:
HM-MOD-EM-8 - die Schaltzustände werden sauber erkannt
HM-LC-SW4-PCB - die Verbraucher lassen sich durch FHEM in die gewünschten Zustände schalten
Das Peering lässt sich einwandfrei setzen und die Schaltänderungen (open/closed) werden auch an den Aktor SW4 als Trigger gesendet.
aber: Der SW4-PCB schaltet aber einfach nicht  :(
Es würde natürlich mit einem Notify gehen - aber genau das möchte ich eigentlich vermeiden.

Nach meinem Verständnis wird durch die Einstellung im Schaltaktor (SW4-PCB) der Schaltzustand bestimmt - bei gesetztem Peering.
Hier am Beispiel des des Kanal 04
EM8_Btn08 Zustand Open -> Ziel - Licht Aus
EM8_Btn08 Zustand Closed -> Ziel - Licht An

Ich habe im Register die CtOn / CtOff werte entsprechend auf geLo / ltLo gesetzt da die Zustände Open/Closed zumindest bei Fensterkontakten ja Vaues 200 | 0 liefern würden.
Ob der HM-MOD-EM-8 auch so macht weiss ich nicht - ich habe es allerdings auch schon andersrum versucht.

Gruß
Benno

Register HM-LC-SW4-PCB Channel SW04

R-EM8_Dunstesse_Btn_08-shActionType        jmpToTarget    2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shCtDlyOff          ltLo          2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shCtDlyOn          geLo          2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shCtOff            ltLo          2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shCtOn              geLo          2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shCtValHi          100            2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shCtValLo          50            2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shMultiExec        off            2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shOffDly            0 s            2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shOffTime          unused        2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shOffTimeMode      absolut        2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shOnDly            0 s            2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shOnTime            unused        2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shOnTimeMode        absolut        2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shSwJtDlyOff        off            2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shSwJtDlyOn        on            2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shSwJtOff          dlyOn          2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shSwJtOn            dlyOff        2023-04-04 00:46:44


frank

R-EM8_Dunstesse_Btn_08-shCtOff            ltLo          2023-04-04 00:46:44
R-EM8_Dunstesse_Btn_08-shCtOn             geLo          2023-04-04 00:46:44
tausche mal diese beiden werte
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

cracalien

Leider keinerlei Effekt
Register werden sauber gesetzt aber der Aktor schaltet nicht über den Peer

frank

#3
sniffe die raw messages beim schalten wie es im wiki "homematic sniffen" beschrieben ist.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

cracalien

#4
Über Ostern war keine Zeit aber heute hab ich es geschafft.
Aus meiner naiver Sicht sieht das auch korrekt aus. Irritierend finde ich nur das es immer 3 Telegramme sind- würde für mich bedeuten das der SW4 nicht antwortet und der EM8 den Retry auslöst bis zum transmitTryMax ?

EM8    3D60C4 08
SW4    3DC728 04

Kontakt am EM 8 auf CLOSED
2023.04.11 14:12:58.375 0: HMUARTLGW myHmUART recv: 01 05 00 00 36 msg: C5 A4 41 3D60C4 3DC728 084100
2023.04.11 14:12:58.654 0: HMUARTLGW myHmUART recv: 01 05 00 00 34 msg: C5 A0 41 3D60C4 3DC728 084100
2023.04.11 14:12:58.916 0: HMUARTLGW myHmUART recv: 01 05 00 00 34 msg: C5 A0 41 3D60C4 3DC728 084100

Kontakt am EM 8 auf OPEN
2023.04.11 14:13:06.672 0: HMUARTLGW myHmUART recv: 01 05 00 00 35 msg: C6 A4 41 3D60C4 3DC728 0842C8
2023.04.11 14:13:06.711 0: HMUARTLGW myHmUART recv: 01 05 00 00 33 msg: C6 A0 41 3D60C4 3DC728 0842C8
2023.04.11 14:13:06.712 0: HMUARTLGW myHmUART recv: 01 05 00 00 34 msg: C6 A0 41 3D60C4 3DC728 0842C8

frank

genau.
oder der aktor kann mit der hohen channelnummer nichts anfangen?
probiere doch mal mit channel1 vom sensor.
abstand zwischen den devices ist ok?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

cracalien

ich bin kurz vor der Kapitulation und der Nutzung von Notifys  :-\

Ich hab alles zurückgesetzt und die Peers neu gesetzt und dachte tatsächlich das Problem gelöst zu haben.

Die Peers funktionierten nach dem Neuanlernen bis ich die beiden HM Devices wieder in der Haube verstaut hatte.
Danach hatte ich ein ziemlich willkürliches Schaltverhalten.

Meine aktuell beste Idee ist das die Funkwellen im Metallkorpus der Haube ne Fette Party schmeißen und es deshalb zwischen den Geräten nicht klappt. Über die Zentrale (FHEM) geht es nach wie vor einwandfrei.
Ich werde also mal die Leitungswege verlängern und versuchen einen der Aktoren aus der Haube rauszulegen.

Vielleicht bringt das ja Abhilfe.
Ich berichte wenn ich neue Ergebnisse habe.

frank

der abstand der devices ist zu klein.
wenn dir jemand ins ohr schreit, verstehst du in der regel auch nichts.  ;)
zusätzlich eventuell noch funk-reflexionen von der haube.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

cracalien

Ich hab die Devices in der Haube jetzt maximal von einander separiert und schon geht's ::)

Irgendwie hatte ich das tatsächlich nicht als Problem erwartet, da die Kommunikation mit der Zentrale ja einwandfrei funktioniert hat.
Auch hab ich an anderen Stellen durchaus auch Devices eng beieinander mit Peers, wo es keine Probleme macht. Wie vermutet ist da die Haube aber vermutlich ein weiterer Faktor.

Aber gut - Danke für den Tipp mit dem Sniffen - das hat mich auf den richtigen Weg gebracht.
Jetzt läuft die Haube autark wie gewohnt und lässt sich zusätzlich mit FHEM wie gewünscht steuern.