[gelöst] SC über virt. device mit RT gepeert, Temp. geht nicht auf Window open

Begonnen von franky08, 28 April 2014, 22:58:54

Vorheriges Thema - Nächstes Thema

franky08

Der Programmcode funktioniert soweit, nur der RT geht immer auf CMD pending und setzt die Temperatur nicht runter.
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

frank

hallo frank,

wenn deine konfiguration aus post 11 noch aktuell ist, solltest du dein notify wohl ein bischen umbauen. im gegensatz zu martins beispiel machst du erst ein postevent und anschliessend erst set burstxmit. jeweils bei close und open. also die reihenfolge ändern.

ausserdem hast du zwischen deinen attr definitionen vom virtuellen btn ebenfals ein set burstxmit versteckt. das könnte der grund sein, weswegen es überhaupt 1 mal funktionierte. lösch den eintrag aber besser.

drittens würde ich das attr msgrepeat=10 vom virtuellen aktor deutlich verkleinern. es wäre sowieso die frage ob das zusammen mit burstxmit überhaupt funktioniert. dann besser auf 0. macht sonst vielleicht noch zusätzlich ärger.

zusätzlich würde eine änderung des notify auf das reading contact vom sc die ausführungshäufigkeit des notify verringern. das ist aber nur ein performance vorschlag.

gruss frank
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

franky08

Hallo frank, Ich klammer mich mittlerweile an alles, starre seit einer Stunde auf CMD pending  :o
Das set burstXmit  in der def. vom virtuellen Button hatte ich vorhin schon wieder rausgenommen.
Hab das notify jetzt mal umgebaut, mal sehen. Wenn ich Martins Beispiel nehme geht der RT auch für ewig auf CMD pending.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

franky08

Der RT bleibt trotzdem hartnäckig und setzt die Temp. nicht runter. Wenn ich den Sec-SC  direkt mit dem RT Peere geht das ohne Probleme.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

franky08

So, Schluss und Ende. Ich lebe dann weiter mit der roten LED vom Sec-SC und peere wieder direkt, ohne virtuellen Button, dass funktioniert ohne 1 Stunde CMD pending!

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

frank

kann es sein, dass dein hmlan mittlerweile das senden eingestellt hat? schau mal unter details was msgloadEst sagt. den hmlan mal vom strom nehmen.

und nach einer änderung im code alle aufgelaufenen pending befehle manuell löschen mit clear msgevents.

gruss frank
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

franky08

Hallo Frank, alles schon gemacht. Der HMLAN ist bei 6% in einer Stunde. Hatte ihn vorhin auch mal vom Strom. Hab jetzt wieder direkt gepeert und geht sofort.
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

frank

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

franky08

Wie gesagt, mit Martin's Codeschnipsel geht es auch nicht. Der RT weigert sich mit einem virtuellen Button zusammenzuarbeiten. Ein SC-Sec drann und schon geht es.
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

frank

ZitatDer RT weigert sich mit einem virtuellen Button zusammenzuarbeiten.

das kann dem doch egal sein. ich habe aber irgendwo gelesen das auch mit nicht hm türmeldern über virtuelle hm-devices erfolgreich mit rts gearbeitet wurde.
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

franky08

Ja, eigendlich kann es dem Teil doch egal sein woher der Befehl kommt das das Fenster offen ist und die WindowOpen Temp eingestellt werden soll.

Und damit einen schönen Feiertag und danke für die Tips

Gute Nacht

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

martinp876

es kann nur am Timing und/oder an der aufweckstrategie haengen... - wann und wie der Burst kommt

franky08

Funktioniert jetzt, es lag am peering vom Virtuellen Button mit dem RT. Der RT hat ewig das peering nicht angenommen. Dank der Hilfe von Gerhard (Mr.P) läuft´s nun endlich.

Schönen Feiertag

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1