tradfri-fhem tester gesucht

Begonnen von justme1968, 19 Januar 2019, 10:26:46

Vorheriges Thema - Nächstes Thema

Intruder1956

Hallo,
der letzte macht das Licht aus  ;) :(

Ich glaube hier tut sich nichts mehr, muss mir wohl eine andere Lösung einfallen lassen.
Habe es zwar zum laufen bekommen, aber noch nicht zufrieden.

Vielleicht sieht man sich im ConBee-Tread oder wo auch immer. Gibt ja noch was anderes *grins*

Gruß Intruder

Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

tomcat.x

Leider habe ich keine Rollos und kann da direkt nicht helfen. Was mir aufgefallen ist, bei Deinem Aufruf ...

Zitat von: Intruder1956 am 17 November 2020, 10:11:20
pi@fhem:~$ /usr/bin/tradfri-fhem


... fehlt "-s <security code>". Das sagt ja aber auch die Meldung. Aber die Verbindung aus fhem scheint ja zu funktionieren, wenn ich mir die lists anschaue.


Zitat von: Intruder1956 am 17 November 2020, 10:11:20
Muss der Signalverstärker angeschlossen sein mit nur FHEM ??

Und der Signalverstärker ist doch für die Verbindung zum Gateway oder? Hat also nichts mit fhem oder dem Modul zu tun, da die nur über das Gateway kommunizieren.


Zitat von: Intruder1956 am 17 November 2020, 10:11:20
Funktioniert das Rollo mit den Befehlen up und down oder muss das bei Eventmap auf up:100 Down:0 geswitcht werden ?

Hier hört es dann bei mir wie gesagt leider auf ...
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Intruder1956

#557
Guten Morgen,
@tomcat.x alles ist gut. Ich musste mich erstmal in der Ikea Sache einarbeiten. Das einzige was ich gemacht habe war alles am Gateway anmelden, das war im ersten Tread nicht passiert. Macht man es richtig geht es auch ;) :D Dann trudelten, die Rollos, Lampen E14/E27, Schalter und Motionsensor ohne sonst irgendwas mit Sicherheitscode einzufügen, (denn der war vorher schon da) in Fhem ein.
Mein DOIF was ich vorher bei meinen Uniroll-Gurtwickler benutzt habe läuft auch mit den Ikea Rollos. Habe nur noch einen Fehler im DOIF

define doRolladen DOIF ([{sunrise(2000,"07:30")}-{sunset(-1800)}|8] or [07:30-{sunset(-1800)}|7]) \
   ((set Ess_Rollo,WZ_Rollo,Schlaf_Rollo,Arbeit_Rollo up),\
   IF ([WernerS4] eq "present") \
      (set  WZ_Rollo_Tuer up))\
DOELSE ((set Ess_Rollo,WZ_Rollo,Schlaf_Rollo,Arbeit_Rollo down),\
   IF ([WernerS4] eq "absent")\
      (set  WZ_Rollo_Tuer down))\

Ich möchte das nach dem IF raushaben, brauche kein present an dem WZ_Rollo_Tuer, (keine Tür mehr und Nichtraucher) das DOELSE muss denke ich bleiben.
IF ([WernerS4] eq "present") \
      (set  WZ_Rollo_Tuer up))\


Habe diese beiden Teile rausgenommen und vor dem ersten SET eine von beiden Klammern entfernt und das Komma hinter "up)," also wie folgt
define doRolladen DOIF ([{sunrise(2000,"07:30")}-{sunset(-1800)}|8] or [07:30-{sunset(-1800)}|7]) \
   (set Ess_Rollo,WZ_Rollo,Schlaf_Rollo,Arbeit_Rollo up)
   
DOELSE (set Ess_Rollo,WZ_Rollo,Schlaf_Rollo,Arbeit_Rollo down)   

läuft aber nicht  :'(

Generell muss ich mal schauen was ich mit dem Ikea Zeug mache, mit welcher Software ich es steuere.
Mit dem Ikea-Gateway, mit dem ConbeeII -Stick oder MQTT2 oder ? Habe alles da. Ich habe noch nicht raus welches das bessere System (Steuerung) dafür ist.

Es wird schon werden, hab ja Zeit :-)

Einen schönen Sonntag

Gruß Werner (Intruder1956)
Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

tomcat.x

Ah, ok. Hat sich so angehört, als ob Du nicht weiterkommst.

Zumindest für Lampen und Steckdosen reicht mir das Gateway. Komplett ohne ginge aus meiner Sicht sowieso nicht, wegen der Updates. Also macht was anderes nur dann Sinn, wenn man es wie Du eh schon hat oder mit der Funktion des Gateways Probleme hat.

Für die Einrichtung der Geräte, Kontrolle der Geräte und Updates habe ich auch die Ikea App installiert. Wenn ich aber die Geräte darüber bedienen müsste, würde ich mir was anderes suchen ;-) Aber als fhem Nutzer ist das weniger ein Thema.

Bei den Rollläden (wie soweit möglich auch bei anderen Geräten) setze ich auf "lokale Intelligenz" bzw. Unabhängigkeit von zentraler Steuerung. Also morgens hoch, abhängig von Zeit oder Sonnenaufgang, abends runter, Verdunkelung bei Sonne, usw. regeln die Aktoren selbst. Über fhem steuere ich dann nur das was unregelmäßig passieren soll. Andererseits steuere ich aber auch Trädfri Lampen über FS20 Bewegungsmelder, was dann natürlich nicht lokal geht.

Wenn ich mehrere Geräte gleichzeitig steuern will, nutze ich dafür LightScene oder structure. Das vereinfacht die Befehle / DOIFs und erleichtert das spätere Hinzufügen/Entfernen von Geräten für bestimmte Situationen.

Vielleicht verstehe ich Dein DOIF nicht ganz, aber löst das nicht mehrfach ein up oder down aus? Mit den Befehlen definiert man ja keinen Zustand, sondern löst einen Befehl aus. Und die Bedingung ist ja dann nicht nur zu einem Zeitpunkt gültig. Aber die (Uhr)zeitliche Steuerung mit DOIFs nutze ich nicht (nur Verzögerung) und es hat ja vorher funktioniert ...
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Intruder1956

Hallo,
ZitatAh, ok. Hat sich so angehört, als ob Du nicht weiterkommst.
zu dem Zeitpunkt kam ich auch nicht weiter  ;)

ZitatVielleicht verstehe ich Dein DOIF nicht ganz, aber löst das nicht mehrfach ein up oder down aus?
ja es reicht ein up und down
es braucht nur morgens um 7.30 bzw. in der Woche später je nach Helligkeit hochfahren und abends bei entsprechender Dunkelheit wieder runterfahren.
Mehr muss es nicht machen :)
Bei Sonnenstand auf mein Haupt hinter dem Fenster, kann ich immer noch manuell bedienen. Sollte ich gerade an dem Fenster sein.
Habe eh keine Sonnensensoren zu den Ikea Rollos

Ich stelle mir gerade die Frage ob man das Ikea Zeug zeitgleich mit dem Gateway und dem ConbeeII betreiben kann.
z.b. Gateway in Fhem und ConbeeeII in ioBroker oder was auch immer.
Wenn es am IKEA-Gateway angemeldet ist, kann man es dann auch noch woanders ConbeeII, MQTT2 oder sonst wo einbinden ?
Es kommen immer mehr Fragen umso mehr ich mich damit beschäftige  :)
Gerade aktuell wegen Umzug neue Wohnung

Gruß Werner (Intruder1956)


Gruß Werner
Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

MadMax-FHEM

#560
Die Zigbee-Geräte können nur mit EINEM Gateway verbunden sein!

CONBEE II geht per mqtt und auch per deCONZ (noch eine Möglichkeit ;)  ).

deCONZ wäre dann wie eine HUE-Bridge in fhem: HUEBridge-Modul

Es gibt auch eine "App": Phoscon

Wie das mit mqtt geht weiß ich nicht, ist aber glaube ich per Wiki recht gut dokumentiert...

Einen Update von Tradfri Geräten kann man auch mit der Anbindung über deCONZ durchführen, gibt irgendwo hier einen "Zigbee Update Thread"...
...sofern man die Update-Dateien hat.

EDIT: https://forum.fhem.de/index.php/topic,107853.msg1018163.html#msg1018163

Ob das auch bei Anbindung per mqtt geht weiß ich nicht, evtl. steht in besagtem Thread etwas dazu...

An fhem können aber mehrere Gateways betrieben werden, also z.B. ein CONBEE II per mqtt ein weiterer per deCONZ eine echte HUE-Bridge oder auch ein Tradfri-Gateway (oder auch mehrere davon)...


Welche Zigbee-Geräte (am besten) mit welchem Gateway gehen, gerade, wenn es um CONBEE II geht, also ob per mqtt oder deCONZ muss man halt jeweils "recherieren"...

Ich hatte mal (zum Spaß) den Tradfri-Gateway laufen allerdings ist der CONBEE II mit deCONZ (ich habe das PI-Aufsteckmodul ist aber "egal") deutlich flexibler bzgl. "Fremdgeräte" bzw. Geräte verschiedener Hersteller...
Und der Support von DE (Dresden Elektronik) eigentlich sehr gut.

Viel Spaß bei der Auswahl ;)

EDIT: wobei das hier nun schon (gewaltig) den Rahmen des Threads verlässt... Eventuell bzgl. was wie wo/Alternativen hin oder her etc. einen neuen Thtread aufmachen...

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)

Intruder1956

Hallo,
Kann mir jemand sagen/schreiben, wieso und warum ich diese Warnungen im Log habe ?

2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_Initialize redefined at ./FHEM/31_HUEDevice.pm line 173, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_devStateIcon redefined at ./FHEM/31_HUEDevice.pm line 209, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_summaryFn redefined at ./FHEM/31_HUEDevice.pm line 271, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_IODevChanged redefined at ./FHEM/31_HUEDevice.pm line 281, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_moveToBridge redefined at ./FHEM/31_HUEDevice.pm line 337, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_Define redefined at ./FHEM/31_HUEDevice.pm line 368, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_Undefine redefined at ./FHEM/31_HUEDevice.pm line 495, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_SetParam redefined at ./FHEM/31_HUEDevice.pm line 510, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_Set redefined at ./FHEM/31_HUEDevice.pm line 749, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_cttorgb redefined at ./FHEM/31_HUEDevice.pm line 1111, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_xyYtorgb redefined at ./FHEM/31_HUEDevice.pm line 1148, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_Get redefined at ./FHEM/31_HUEDevice.pm line 1195, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_ReadFromServer redefined at ./FHEM/31_HUEDevice.pm line 1291, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_GetUpdate redefined at ./FHEM/31_HUEDevice.pm line 1308, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDeviceSetIcon redefined at ./FHEM/31_HUEDevice.pm line 1353, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_Parse redefined at ./FHEM/31_HUEDevice.pm line 1386, <$fh> line 968.
2020.12.01 16:26:49 1: PERL WARNING: Subroutine HUEDevice_Attr redefined at ./FHEM/31_HUEDevice.pm line 1900, <$fh> line 968.
2020.12.01 16:26:49 3: Ess_Lampe_links: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schalter_Ess_Licht: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Ess_Lampe_rechts: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schalter_Flur_Licht: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Flur_Licht: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Ess_Licht_all: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schalter_Schlaf_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUESensor65553: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUESensor65556: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schalter_WZ_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: WZ_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schlaf_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Ess_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Flur_Motion: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schalter_Ess_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schalter_Arbeit_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Arbeit_Rollo: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Arbeit_Licht_all: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Schalter_Arbeit_Licht: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Arbeit_Licht_2: I/O device is TradfriGateway
2020.12.01 16:26:49 3: Arbeit_Licht_1: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUESensor65564: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUEGroup131079: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUEGroup131080: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUEGroup131086: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUEGroup131088: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUEGroup131089: I/O device is TradfriGateway
2020.12.01 16:26:49 3: HUEGroup131091: I/O device is TradfriGateway


Kann oder muß ich das beseitigen ?

Vielen Dank und Gruß

Werner
Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

DeeSPe

Hallo Andre,

ist es so gewünscht dass die set-Befehle keine Events auslösen?
Ich möchte gern das down-Event von meinen Rollos auswerten. Wenn das zugehörige Fenster geöffnet ist soll das Rollo nicht weiter runterfahren, sondern bei einem bestimmten pct Wert stehen bleiben. Leider kann ich bisher nur auf den pct Wert per notify reagieren (pct < 90), dieses reagiert dann aber auch beim Hochfahren wieder und fährt das Rollo wieder ein Stück runter da man an den Readings nicht erkennt ob das Rollo öffnet oder schließt.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

JoWiemann

Zitat von: DeeSPe am 10 Februar 2021, 19:30:09
Hallo Andre,

ist es so gewünscht dass die set-Befehle keine Events auslösen?

Works as designed: https://wiki.fhem.de/wiki/Event

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

justme1968

set befehle (auch get) lösen niemals events aus. nur änderungen an readings tun das. down ist auch gar kein 'echtes' kommando sondern wird intern noch umgesetzt.

wenn du nur aus fhem heraus steuerst könnte man das mit einem cmdalias regeln der down abfängt und den aktuellen stand mit auswertet. das erscheint mir auf den ersten blick als die sauberste lösung.

wenn du nicht aus fhem heraus steuerst geht das sowieso nur in dem du das notify auf alle pct werte reagieren lässt, dir die richtung merkst und rechtzeitig abbrichst.

im prinzip könnte man im modul auch den vorherigen wert zur verfügung stellen, aber wo macht man dann schluss. dafür gibt es zu viele readings.

nicht ganz sauber und ohne garantie auf ewige gültigkeit: in $defs{$name}->{helper}{pct} müsstest du im notify denjeweils vorherigen wert finden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

DeeSPe

Moin Jörg und Andre,

hab mich natürlich wieder mal nicht richtig ausgedrückt. ;)
Klar lösen set- und get-Befehle keine Events aus, sondern die Readings.

Ich habe es, wie Andre vorgeschlagen hat, mit einem cmdalias probiert. Das funktionierte auch wie gewünscht solange man ausschließlich über FHEM steuert, das hatte Andre auch bereits erwähnt. Da man das Rollo aber auch am Rollo selbst oder per Fernbedienung steuern kann, war mir das nicht ausreichend.

Für meine aktuelle Lösung habe ich ein userReading gebaut welches das Reading "direction" setzt. Dazu benutze ich OldReadingsVal. Es setzt bei Werten zwischen 1 und 99 das Reading entsprechend zum vorhergehenden Wert auf "opening" oder "closing". Bei Werten von 0 und 100 wird das Reading auf "stopped" gesetzt. Ein zusätzlicher watchdog setzt das Reading "direction" auf "stopped" wenn sich der pct Wert (zwischen 1 und 99) nach 3 Sekunden nicht mehr ändert. Als Letztes kommt natürlich noch ein notify zum Einsatz, welches das Reading "direction" auswertet und entsprechend reagiert.
Das funktioniert nun so wie ich es wollte.

Hier meine Definitions-Schnipsel falls das jemand nachbauen möchte.
Zusätzliche Attribute für das Rollo:

attr dz_Rollo oldreadings pct
attr dz_Rollo userReadings direction:pct:.* {\
  my $v = ReadingsVal($NAME,"pct",0);;\
  return "stopped" if ($v=~/^(0|100)$/);;\
  OldReadingsVal($NAME,"pct",0)>$v?"closing":"opening";;\
}

Der watchdog:

defmod wd_dz_Rollo_pct watchdog dz_Rollo:pct:.[1-9]\d? 00:00:03 dz_Rollo:pct:.[1-9]\d? setreading dz_Rollo:FILTER=direction!=stopped direction stopped
attr wd_dz_Rollo_pct autoRestart 1

Und hier das passende notify:

defmod n_dz_Rollo_direction notify dz_Rollo:direction:.* {\
  if ($EVTPART1 eq "closing") {\
    if (Value("dz_Fenster") ne "closed"){\
      say ("Das Rollo kann leider nicht heruntergefahren werden da das Fenster noch offen ist! Bitte schließe erst das Fenster und versuche es dann erneut!","dz_Sonos");;\
      fhem "set dz_Rollo pct 95";;\
    }\
  }\
}



Hier noch die Definition für cmdalias, welchen ich aber nicht mehr benutze:

defmod ca_set_dz_Rollo_down cmdalias set dz_Rollo down AS {\
  if (Value("dz_Fenster") ne "closed") {\
    fhem "set dz_Rollo pct 95";;\
  } else {\
    fhem "set dz_Rollo pct 0";;\
  }\
}



@Andre:
Wäre es nicht evtl. sinnvoll diese Werte (bei mir Reading "direction") direkt aus dem Modul in das Reading "state" zu schreiben, denn der aktuelle Öffnungsgrad des Rollo steht ja im Reading "pct" und wird eigentlich in "state" nicht noch zusätzlich benötigt.
Oder evtl. einfach nur bei den set-Befehlen, bevor sich das Reading "state" entprechend dem Reading "pct" mitändert, kurz auf (je nach set-Befehl) "down" bzw. "up" zu setzen damit ein entsprechend auszuwertendes Event kommt?
Verstehe mich nicht falsch, es funktioniert mit diesen Definitionen nun so wie ich es wünsche, nur könnte es evtl. noch komfortabler werden. Zwischen dem Schreiben des "pct" Readings und dem entsprechenden Reagieren darauf ist nämlich eine nicht zu vernachlässigende Verzögerung. Ich habe glücklicherweise das Rollo an der Decke befestigt und somit 13% Weg um es bei offenem Fenster noch "aufzuhalten". Viel kürzer dürfte der Weg auch nicht sein damit das "Aufhaltekommando" noch rechtzeitig kommt bevor das Rollo auf dem Fenster aufsetzt.

Vielen Dank für Eure Hilfe.

Gruß
Dan

BTW: Vielen Dank für das tolle Modul Andre! Mal wieder!!! ;)
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

justme1968

versuch mal ob die angehängte version macht was du möchtest.

das ganze landet aber nicht in state (das würde bei vielen probleme mit den icons machen) sondern es wird wie bei dir ein reading direction erzeugt das die werte unknown, stopped, closing oder opening annehmen kann.

das mit dem timer habe ich erst mal nicht eingebaut. da ich vermute das auf jeden fall ein wert kommt wenn der motor angehalten wird. ist aber ungetestet.

das mit der verzögerung verstehe ich nicht ganz. die readings werden geschrieben sobald etwas vom device empfangen wird. schneller geht es nicht. es gibt verzögerungen auf device seite da der rolladen  vermutlich nicht immer sofort etwas ans gateway sendet und das gateway nicht unbedingt sofort weiter an fhem. dagegen lässt sich aber nichts machen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

DeeSPe

Zitat von: justme1968 am 11 Februar 2021, 19:04:09
versuch mal ob die angehängte version macht was du möchtest.

das ganze landet aber nicht in state (das würde bei vielen probleme mit den icons machen) sondern es wird wie bei dir ein reading direction erzeugt das die werte unknown, stopped, closing oder opening annehmen kann.

Du bist ja wieder mal schneller als die Feuerwehr. ;)
Es funktioniert auch soweit fast perfekt, denn eine Sache ist komisch. Mein notify für "closing" wird 3x getriggert, das war mit dem userReading nicht so.
Hab das mal in einer readingsHistory geloggt:

19:25:30  Rollo Zimmer Dan direction: stopped
19:25:26  Rollo Zimmer Dan direction: opening
19:25:25  Rollo Zimmer Dan direction: stopped
19:25:25  Rollo Zimmer Dan direction: closing
19:25:24  Rollo Zimmer Dan direction: stopped
19:25:24  Rollo Zimmer Dan direction: closing
19:25:23  Rollo Zimmer Dan direction: stopped
19:25:23  Rollo Zimmer Dan direction: closing


Statt "closing/stopped/closing/stopped/closing/stopped/opening/stopped" hätte kommen sollen "closing/stopped/opening/stopped". Warum der vor dem Hochfahren noch 2x "closing/stopped" dazwischen quetscht ist mir nicht ganz klar.

Die Sache mit der Verzögerung hatte ich nicht Dir bzw. dem Modul angelastet, sondern nur festgestellt. Das ist eben einfach so und lässt sich sicherlich nicht weiter optimieren. Mit der aktuellen Erweiterung von heute löst das notify auf jeden Fall schneller aus, da nicht erst gewartet werden muss bis sich das "pct" Reading das erste mal ändert und somit das userReading geschrieben wird und das notify auslöst.

Vielen Dank für Deinen Einsatz.

Gruß
Dan

P.S. Was ist eigentlich mit diesen Shortcut-Buttons? Gibt es bei denen wirklich keinen Weg dessen Betätigung in FHEM anzuzeigen. Ich hatte gehofft mit denen etwas mehr machen zu können als nur Szenen in der IKEA App zuzuweisen.
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

justme1968

die seltsame event reihenfolge kann ich nicht reproduzieren. schau mal ob du mit inform und oder debug 5 mehr raus findest. vor allem schau was in pct steht und welche daten vom ikea gateway kommen.

könnt es eventuell sein das dein notify noch aktiv ist und dazwischen funkt?

ich hatte vorhin vergessen noch zu erwähnen das ich glaube das in deinem notify für 0% und 100% die richtung genau so mit berücksichtig werden muss wie bei den zwischen werten.


so lange das node backend modul das mit dem gateway redet da nichts einbaut komme ich nicht an die daten. und der stand dort ist bisher das das gateway schon nichts meldet.

mit deconz kommst du hier vermutlich weiter. da ist die rollo integration aber nicht so schön :)



hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

DeeSPe

Das ist sehr merkwürdig. Sobald ich das notify deaktiviere stimmen die Events. Auch wenn ich das was das notify machen soll manuell mache, also kurz vor dem Aufsetzen des Rollos wieder auf "pct 95" setze, stimmen die Events. Sobald das notify aktiv ist kommt es zu diesen unerklärlichen Events. Ich habe sonst natürlich alles andere (userReadings+watchdog) zum Test entfernt. Ich verstehe es nicht, denn bei meiner selbstgebastelten Lösung war das kein Problem.

Ach und noch eine Kleinigkeit ist mir "unangenehm" aufgefallen. ;)
Wenn man das Rollo beim Hoch- bzw. Runterfahren stoppt und dann in die selbe Richtung weiterfährt, wird das Reading "direction" nicht noch einmal gesetzt. Das wäre natürlich schön da es beim manuellen Anhalten kein "stopped" gibt, sondern nur an den Endanschlägen und ich, um das zu ändern, normalerweise noch den watchdog im Einsatz habe.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe