Neues Modul: 98_Siro.pm (Ansteuerung von motorisierten Innensichtschutzrollos)

Begonnen von Dr. Smag, 27 September 2017, 00:14:49

Vorheriges Thema - Nächstes Thema

Byte09

wenn du es nicht anders konfigurieren kannst im motor melde dich nochmal, ich denke ich weiss wie das realisiert ist von siro und könnte das modul anpassen - wenn unvermeidbar.

gruss byte09

Dr. Smag

Zitat@Dr. Smag: was heißt das mit der Timingverbesserung genau? Soll jetzt nicht mehr die im ersten Beitrag verlinkte Datei genommen werden? Löst dies evtl. Mein Problem?
D.h., dass die Rollo's noch besser reagieren. Das hat aber nichts mit deiner Situation zu tun. Ich habe extra noch die "alte" 00_SIGNALduino.pm auf dem Server gelassen, bis alles im Grünen ist.

ZitatRucken meint, sie machen einen Minischritt
Damit hatte ich mich auch mal gequält. Habe ich hier auch schonmal erwähnt:
https://forum.fhem.de/index.php/topic,12227.msg657791.html#msg657791

Der Motor befindet sich noch im Programmiermodus. Da kommst du nur mit der P2-Taste und Hoch, Stopp oder Runter der FB raus. Jenachdem, in welchem Modus du dich befindest.

Am einfachsten ist es die Motoren zurückzusetzen, dann sind deine Probleme weg.

Den Taster am Motor so lange gedrückt halten. bis er 3x jeweils 1x bestätigt hat.

Dann natürlich neu pairen.

LG.
RPi1,2,3,HMLAN,HM,CC-RT-DN,HM-TC-IT-WM-W-EU,HM-LC-SW2-PB-FM,HM-LC-Sw1PBU-FM,HM-LC-Dim1TPBU-FM,HM-SEC-RHS,HM-SEC-KEY-S,HM-SEC-S,C, HM-OU-LED16,HM-ES-PMSw1-Pl,HM-RC-Dis-H-x-EU,HM-LC-SW4-DR,HM-RC-8,HM-OU-CFM-TW,HM-SEC-WDS, HM-PB-2-WM55,HM-Sen-MDIR-O,HM-Dis-WM55,HM-Dis-EP-WM55,HM-ES-PMSw1-Pl-DN-R1...

volschin

Eine kleine Vereinfachung für das Attribut devStateIcon hätte ich anzubieten.
{return '.*:fts_shutter_1w_'.(int($state/10)*10)}
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

Dr. Smag

RPi1,2,3,HMLAN,HM,CC-RT-DN,HM-TC-IT-WM-W-EU,HM-LC-SW2-PB-FM,HM-LC-Sw1PBU-FM,HM-LC-Dim1TPBU-FM,HM-SEC-RHS,HM-SEC-KEY-S,HM-SEC-S,C, HM-OU-LED16,HM-ES-PMSw1-Pl,HM-RC-Dis-H-x-EU,HM-LC-SW4-DR,HM-RC-8,HM-OU-CFM-TW,HM-SEC-WDS, HM-PB-2-WM55,HM-Sen-MDIR-O,HM-Dis-WM55,HM-Dis-EP-WM55,HM-ES-PMSw1-Pl-DN-R1...

Byte09

Zitat von: volschin am 03 Oktober 2017, 11:03:42
Eine kleine Vereinfachung für das Attribut devStateIcon hätte ich anzubieten.
{return '.*:fts_shutter_1w_'.(int($state/10)*10)}

ja, da habe ich irgendwie auf "möglichst kompliziert" gestanden.  ;)

ich ändere das entsprechend .

gruss Byte09

Byte09

INFO:

das Modul Siro ist in aktueller Version noch nicht an die "offizielle" 00_Signalduino. pm aus der rev-33 angepasst und wird mit dieser Version der Signalduino nur fehlerhaft funktionieren, insbesondere was den Empfang (parsen) der Fernbedienung betrifft.

Bedingt ist dieses daher, das das Siromodul nun Aufgaben übernehmen muss, die das Signalduinomodul bisher übernahm , nun aber - für das Siroprotokoll - nicht mehr übernimmt ( auf unseren Wunsch hin ) . Diese Änderung war zwingend erforderlich , um auf den Befehl "Favoritenanfahrt" von der Fernbedienung reagieren zu können.

Diese Fehler werden sich insbesondere bei der Stateerrechnung bemerkbar machen, wenn Fahrten durch die Fernbedienung ausgelöst werden. Hier wird eine deutlich höhere Serverlast ausgelöst, da schon ein kurzes drücken der Fernbedienungstaste , zig Parseanfragen auslösen, die nicht gefiltert - und somit alle - abgearbeitet werden.

In verbindung mit dem Siromodul ist es hier sinnvoll, bis zur Aktualisierung auf die hier verlinkte 00_Signalduino zurückzugreifen, sofern die neue Signalduino aus anderen Gründen nicht zwingend benötigt wird.

Weiter Neuerung :

In der aktualisierten Version der Signalduino gibt es ein neues Attribut "development". Dieses muss zwingend auf "m72m72.1" gesetzt werden , solange das Siromodul noch nicht offiziell in der SVN repository ist .

Eine aktualisierte Version des Siromoduls wird kurzfristig in den nächsten Tagen folgen , Dr. Smag und ich arbeiten daran.

gruss Byte09




volschin

Zitat von: Dr. Smag am 03 Oktober 2017, 11:08:29
Hat es denn geholfen?
Ja, nur leider sind auch meine Einstellungen erstmal weg.  :o

Ich kümmer mich jetzt erstmal um die HomeKit-Ansteuerung bei den beiden eingerichteten.  :)
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

volschin

Die Logik des Siro-Moduls ist leider konträr zu der, der meisten anderen Jalousien, bei denen 100 offen und 0 geschlossen heißt.

Aber auch das kann man mit etwas Aufwand für HomeKit richten:

genericDeviceType blind
homebridgeMapping TargetPosition=position,cmd=position,cmds=100:on,invert=1,minValue=0,maxValue=100,minStep=1
CurrentPosition=position,cmd=position,invert=1,minValue=0,maxValue=100,minStep=1
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

Dr. Smag

Dem sehe ich nicht so. Das Dooya ist ebenso aufgebaut.
Meine allerersten Experimente, bevor ich mit dem Modul anfing waren auch so.

Das Dooya, welches 0 (offen) und 100 (zu) ebenfalls entspricht, ist besser und logisch.

Bsp.:
0% Licht bedeutet kein Licht.

0% Rollo eben kein Rollo. Somit kein Rollo.
100 steht für 100% Rollo, also maximal ausgefahren.
Es geht ja nicht um Licht sondern um das Rollo und somit wie weit das Rollo sozusagen "da" ist.

Siehe zweiten Post des Threads. Der User Invers sieht es auch so.

Ich selbst spreche die Rollos sowieso nicht direkt an, da ich noch vorher überprüfe, ob
z.B. das Fenster geöffnet ist. In dieser Wrapper-Funktion kannst du ja ein 100-x einbauen.

Ob wir eine Value-Invertierung implementieren, weiss ich derzeit noch nicht.
Erstmal muss es sauber laufen. Aber danke für deinem Hinweis.
RPi1,2,3,HMLAN,HM,CC-RT-DN,HM-TC-IT-WM-W-EU,HM-LC-SW2-PB-FM,HM-LC-Sw1PBU-FM,HM-LC-Dim1TPBU-FM,HM-SEC-RHS,HM-SEC-KEY-S,HM-SEC-S,C, HM-OU-LED16,HM-ES-PMSw1-Pl,HM-RC-Dis-H-x-EU,HM-LC-SW4-DR,HM-RC-8,HM-OU-CFM-TW,HM-SEC-WDS, HM-PB-2-WM55,HM-Sen-MDIR-O,HM-Dis-WM55,HM-Dis-EP-WM55,HM-ES-PMSw1-Pl-DN-R1...

volschin

Und Apple sagt (wie ca. 9 von 10 Herstellern): 0% = kein Licht, also Rollo zu.
Ist die Frage, ob es aus Kompatibilitätssicht Sinn macht, gegen den Strom der Großen zu schwimmen?
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

Invers

Aber on und off halte trotzdem Quatsch. Ein Motor oder eine Lampe kann on sein, aber kein Rollo.
Ausnahme: Das Rollo läuft gerade. Wäre cool, geht aber nicht, weil das Rollo nichts sendet.
Klar kann man auch andere Befehle nehmen, ist aber eigfentlich Überflüssig.
Braucht man wirklich 0 und 100? Ja! Aber on und off? Wie die anderen Kandidaten überflüssig.
Open und closed wären mögliche Kandidaten, sind aber auch überflüssig, weil das ja schon mit 0 und 100 dargestellt wird.
Aber wer wseiss, vielleicht sagt ja wirklich jemand zu seiner Frau: Liebling, mach mal das Rollo aus. :-)
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Byte09

hmmm,

also "on und off "war zwischen dr. smag und mir auch schon ein thema bei dem unsere meinungen etwas auseinanderdriften. da sehe ich aber nicht das problem , da das ja über webcmd wirklich ohne aufwand anzupassen ist. Ansonsten tauchen die beiden Begriffe ja nirgends auf. Da das Modul selbst auch open und close versteht ist das wohl nicht das thema.

0%, 100% ist wohl wirklich eine frage des gefühls unabhängig vom "strom". ich betreibe einen haufen homematicaktoren die ebenfalls 0% als rollo geschlossen darstellen - dieses fühlt sich aus meiner sicht völlig falsch an.

ZitatIst die Frage, ob es aus Kompatibilitätssicht Sinn macht, gegen den Strom der Großen zu schwimmen?
.... diese Aussage/Frage ist aber sicher nicht ganz unbegründet.

Ich werde eine Invertierung ( allerdings über Attribut ) auf meine TodoListe setzen und sehen inwieweit es machbar ist, ohne das ganze modul umzustricken .
Ist aber eine lange Liste , mit vielen Dingen die höhere priorität haben.

gruss Byte09

Invers

Zitatalso "on und off "war zwischen dr. smag und mir auch schon ein thema bei dem unsere meinungen etwas auseinanderdriften. da sehe ich aber nicht das problem , da das ja über webcmd wirklich ohne aufwand anzupassen ist. Ansonsten tauchen die beiden Begriffe ja nirgends auf. Da das Modul selbst auch open und close versteht ist das wohl nicht das thema.

Taucht aber auch bei Nichtnutzung im Log auf. Ich schalte mit 0 und 100 Prozent, ohne Webcmd.
Beispiel:
2017.10.01 07:19:39 1: Siro_sendCommand: Siro_SZL off
2017.10.01 07:19:39 1: Siro_sendCommand: execute comand off - sendMsg to HASH(0x3601e80) channel 3 -> P69#1000010000110001010011001101001100010001#R9


Die Prozentangabe würde ich nicht ändern. Nur weil Andere es umgekehrt deuten, muss es ja nicht stimmen.
Sollten sich Attribute nicht lieber auf das Device beziehen, statt auf die Umwelt?
Mal weitergesponnen, ist es überhaupt richtiger, sich auf das Licht, statt auf das Rollo zu beziehen?
Licht komplett weg wäre ja nicht dann, wenn das Rollo zu ist, sondern es müsste ja dann auch noch lichtdicht sein, damit diese Aussage stimmt.

Ich will nicht meine Meinung durchsetzen. Ich verstehe nur nicht, warum nun wegen der Prozentdiskussion ein Attribut eingeführt werden soll. Kann man doch auch mit webcmd totschlagen, wobei mir eventMap in beiden Fällen logischer erscheint.

Es ist eure Entscheidung, da ihr Freizeit, Schweiss und Gehirnschmalz investiert habt. Meine Einwände sollten nur konstruktive Hinweise sein.  Ich hatte diesbezüglich nur noch einmal geschrieben, weil ich den Eindruck hatte, dass ich missverstanden wurde und wollte meine Sichtweise daher differenzierter darstellen.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Dr. Smag

Das sehe ich ebenfalls so.

Über "an" und "aus", kann man sich natürlich streiten. In der Terminologie "richtig" wäre es, so wie es Byte09 auch schon sagte: "Oben und unten".

Zu den Prozentwerten: Ja, es sollte sich auf das Gerät beziehen, so wie es "Invers" auch schon sagte. Dabei ist 0% oder "aus", der "Urzustand" des Gerätes, also wenn es nicht da oder aktiv ist.

Ein paar Beispiele:
Licht: Urzustand: 0 Lumen -> 0% = aus; 100% = maximale Helligkeit;
Strom: Urzstand: 0 Ampere -> 0% = aus; 100%= maximaler Strom;
Türverriegelung: Urzustand: nicht verriegelt -> 0% = aus; 100% = maximale Verriegelung;
Lautstärke: Urzustand: kein Ton 0% = aus; 100% = maximale Lautstärke;
Rollo: Urzustand: Keine Abdeckung = 0% = kein Rollo = aus; 100% = maximales Flächenabdeckung;
Heizung: 0% = keine Heizung = aus; 100% = maximale Heizkraft;

Es macht keinen Sinn Prozentangaben auf andere Dimensionen zu legen. Ein Rollo hat die Funktion die Lichtstärke zu dimmen oder besser gesagt eine Fläche abzudecken. Stelle ich es auf 10%, wird auch 10% der Fläche abgedeckt.
RPi1,2,3,HMLAN,HM,CC-RT-DN,HM-TC-IT-WM-W-EU,HM-LC-SW2-PB-FM,HM-LC-Sw1PBU-FM,HM-LC-Dim1TPBU-FM,HM-SEC-RHS,HM-SEC-KEY-S,HM-SEC-S,C, HM-OU-LED16,HM-ES-PMSw1-Pl,HM-RC-Dis-H-x-EU,HM-LC-SW4-DR,HM-RC-8,HM-OU-CFM-TW,HM-SEC-WDS, HM-PB-2-WM55,HM-Sen-MDIR-O,HM-Dis-WM55,HM-Dis-EP-WM55,HM-ES-PMSw1-Pl-DN-R1...

Byte09

hi,

die neue version des Siromuduls ist im grunde fertig, inclusive der anpassungen an die neue signalduino.pm.

weiterhin beinhaltet sie einige änderungsvorschläge, deutlich bessere erkennung der fernbedienung , deutlich bessere erkennung des fb-befehls für favoritenanfahrt.

die parse-routine ( empfang FB ) habe ich komlpett erneuert , diese arbeitet nun erheblich schneller . leider musste ich hierfür die struktur der abgelegten daten ändern, d.H es ist zwingend erforderlich die devices zu löschen und neu anzulegen .

anfangs schrieb ich "im grunde" ......

"Im Grunde" daher , da diese Version nur bedingt lauffähig ist , in verbindung mit dem SignalESP , d.H hier wird es zu massiven fehlern beim empfang der fernbedienung kommen. 

Sidey ( maintainer signalduino ) kennt das problem, arbeitet auch an einer lösung , kann aber noch nicht sagen , wie lange es dauern wird.

insofern werde ich noch ein paar tage warten , in der hoffnung , das dieses problem kurzfristig zu lösen ist . andernfalls werde ich die gesamte parse-routine nochmals ändern müssen , so dass sie mit dem ESP zumindest eingeschränkt funktioniert.

gruss Byte09