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

[Invers]

hi invers,

ich werde ein reading 'motor-term' einbauen, welches einfach die motorlaufzeit mitzählt und bei , aber nur dann ein event auslöst , wenn ein im attr gesetzter wert erreicht wird. resetbar per 'set ...'

gruss Byte09

Da haben sich unsere Beiträge überschnitten.
Die Idee finde ich noch cooler, als meine. Dann würde ja auch eine Verschiebung stattfinden, wenn man das Rollo mehrmals täglich bewegt.
Da meine Rollos aber trotz unterschiedlicher Länge und Breite die selbe Akkulaufzeit haben, müsste man das auch per "Hand" rücksetzen können.
Ich hatte ja bei meinen Rollos festgestellt, dass sich die Länge und Breite nicht auf die Akkulaufzeit ausgewirkt haben. Bei mir sind es immer 48 Tage. Zur Vorsicht habe ich mich alle 45 Tage erinnern lassen (von Outlook).

Vielleicht könnte sich ja mal jemand über seine Akkulaufzeiten äussern.
Am komfortabelsten wäre, beide Möglichkeiten zur Verfügung zu haben, die man dann auswählen kann.
Ich bin allerdings nicht in der Lage, den Aufwand einzuschätzen. Das musst du entscheiden, ob es dir die Mühe wert wäre.

[Byte09]

ich habe den zähler eingebaut. Wenn du mir jetzt nochmal sagst, was du genau für eine Logzeile, mit welchen Infos, bei welchem Verbose haben möchtest, würde ich das jetzt noch ändern und die version dann erstaml in obigem post aktualisieren

gruss Byte09

[Byte09]

..... Am komfortabelsten wäre, beide Möglichkeiten zur Verfügung zu haben, die man dann auswählen kann. .....

sind nun beide drinnen .

gruss Byte09

[Invers]

Du bist ja schneller, als der Blitz.
Ich meinte diese Zeile bei verbose 3
Siro_set: handing over to Siro_Send_Command with following arguments: off 80 0 Kanal 4
So in dieser Art.
Die anderen Meldungen /Zeilen könnten dann wieder weg. Man sieht ja dann hier schon alles, was für den Nutzer interessant ist.

Nochmals danke.

[Byte09]

aktualisierte version hier :

https://forum.fhem.de/index.php/topic,77167.msg754991.html#msg754991

gruss Byte09


ich hoffe das er die tage auch zählt, wissen wir dann morgen genau .   mag jetzt meine systemzeit auf dem RPi nicht wirklich umstellen .

wird nicht um 00.00 uhr aktualisiert, sondern immer um die zeit , zu der der letzte reset stattgefunden hat.

[Invers]

Danke dir, probier ich sofort aus! Bin voll begeistert!

[Byte09]

Danke dir, probier ich sofort aus! Bin voll begeistert!

das war jetzt ein ziemlicher schnellschuss .... falls es nicht läuft gib bitte einfach bescheid. - mag es daher auch noch nicht ins svn einspielen. ggf. mache ich dieneuen readings auch noch per attr an-, bzw abschaltbar .

gruss Byte09

[Invers]

Kurztest abgeschlossen.
Verbose funktioniert hervorragend. So habe ich mir die Meldungen vorgestellt!

Berechnung der Rollo-Laufzeit funktioniert ebenfalls, könnte aber einen kleinen Denk- oder Rechenfehler enthalten.
Rollo von zu auf 80 Prozent fahren zeigt 3,52 Sekunden. Rollo wieder auf zu zeigt 7,9 Sekunden, wenn ich aber das Rollo mit set Siro_SZL 100 schalte, kommt dann 8,1 raus. Also nie das doppelte von 3,52. Ich weiss nun leider nicht, wie die Laufzeit abgegriffen wird. Ist auch nicht besonders schädlich, denke ich. Ich wollte es nur mitteilen. Wenn die Differenz monatlich nur 20 Sekunden beträgt, dann juckt das eigentlich nicht. Wollte nur ordentlich arbeiten. Lacht.

Vielen Dank für die gute Arbeit und schnelle Erfüllung meiner Wünsche.

[Byte09]

Kurztest abgeschlossen.
Verbose funktioniert hervorragend. So habe ich mir die Meldungen vorgestellt!

Berechnung der Rollo-Laufzeit funktioniert ebenfalls, könnte aber einen kleinen Denk- oder Rechenfehler enthalten.
Rollo von zu auf 80 Prozent fahren zeigt 3,52 Sekunden. Rollo wieder auf zu zeigt 7,9 Sekunden, wenn ich aber das Rollo mit set Siro_SZL 100 schalte, kommt dann 8,1 raus. Also nie das doppelte von 3,52. Ich weiss nun leider nicht, wie die Laufzeit abgegriffen wird. Ist auch nicht besonders schädlich, denke ich. Ich wollte es nur mitteilen. Wenn die Differenz monatlich nur 20 Sekunden beträgt, dann juckt das eigentlich nicht. Wollte nur ordentlich arbeiten. Lacht.

Vielen Dank für die gute Arbeit und schnelle Erfüllung meiner Wünsche.

hmmm , muss ich mir nochmal anschauen mit den zeiten , aber nicht mehr heute. Wobei 80% runterfahren und 80% hochfahren ja andere laufzeiten sind, abhängig von deinen eingetragenen attr. bei eine komplettfahrt , ohne dass ein stopbefehl erfolgt , rechnet er eine Sekunde hinzu , die er nicht gefahren ist . das ist daherbedingt , dass ich bei der schaltung des states ( und da greife ich die zeit ab ) , bei komplettfahrten , eine reservesekunde zugegeben habe, um tolerenzan zwischen der errechneten fahrdauer und der realen fahrdauer bei einer komplettfahrt immer auszugleichen .

............. aber wir haben ja schon einen kompletten arbeitstag hinter uns, von daher : denkfehler nicht ausgeschlossen .... ich prüfe es morgen , damit ich mich denn wieder MSwitch zuwenden kann 

Gruss Byte09

[Invers]

Ich bin natürlich von 100 (geschlossen) auf 80 und dann wieder auf 100 gefahren, so dass die Laufzeit in beiden Fällen nur 20 Prozent sind.
Aber wie gesagt, ist eigentlich momentan zumindest noch nicht schädlich.
Eine Zählung des Tages konnte ich noch nicht beobachten. Kann aber daran liegen, dass vielleicht erst heute Abend gezählt wird, in Abhängigkeit meines Resets.
Der Rest scheint super zu laufen. Bei der Erstnutzung kam eine Perlwarnung, aber das ist ja klar.
Die Differenz ist ja auch nicht kritisch. Bei 45 Tagen geht vielleicht eine Minute an Genauigkeit verloren. Wir brauchen aber gar keine Atomuhr. Ist ja nur eine Ladeerinnerung. Selbst 8 Stunden würden da nicht ins Gewicht fallen. Also mach dir keinen Kopf deswegen.


NACHTRAG!
Mir ist aufgefallen, dass die beien Readings auch für gruppe 0 vorhanden sind, allerdings mit wildem Wert.

List:

Internals:
   CFGFN     
   CHANNEL    0
   DEF        84314CD0
   ID         84314CD
   INFO       This is a group Device with limited functions affected the following devices:
Siro_SZL Siro_WZL Siro_WZR Siro_SZR
   IODev      sduino
   NAME       Siro_0
   NR         433
   NTFY_ORDER 50-Siro_0
   STATE      0
   TYPE       Siro
   Version    V 0.48
   state      0
   CODE:
     1          84314CD0
   READINGS:
     2018-01-25 08:14:12   action          no action
     2018-01-24 19:55:10   last_reset_os   0
     2018-01-25 08:14:12   operating_seconds 6067456676.02
     2018-01-25 08:14:11   position        0
     2018-01-25 08:14:11   state           0
   helper:
     LastMODE   physical
     MODE       physical
     affected_devices_h HASH(0x3cfeeb8),HASH(0x3cf3b98),HASH(0x3cf4560),HASH(0x3d77358)
     affected_devices_n Siro_SZL,Siro_WZL,Siro_WZR,Siro_SZR
     aktMsg     off 0 1516864451.0341
     groupcommand off,off,,HASH(0x3d25408)
     lastMsg    off 0 1516864302.48274
     lastProg   0
     lastparse 
     lastparse_stop stop 1509953292.10412
     parse_aborted 0
     position   0
     positiontimer 148.5
Attributes:
   IODev      sduino
   SignalLongStopRepeats 15
   SignalRepeats 8
   cmdIcon    50:rc_RIGHT@gold off:rc_UP@gold on:rc_DOWN@gold stop:rc_STOP@gold
   devStateIcon {return '.*:fts_shutter_'.(int($state/10)*10).'@gold'}
   down_auto_stop 0
   eventMap   /position 50:50/
   invers_position 0
   room       Rollo
   webCmd     stop:on:off:50

Die Frage ist, ob wir es da überhaupt brauchen. Ich denke, nicht. Ich habe allerdings keine Idee, ob und wie man das abfangen kann, wenn jemand die Gruppe fährt.  Vielleicht so, dass man dam jeweiligen einzelnen Device den Wert der Gruppe hinzurechnet. Das müsste dann allerdings wahrscheinlich vom Nutzer bei der Auswertung erledigt werden. In dem Fall müssten dann allerdings auch für Gruppe 0 doch die Readings gefüllt werden. Dass allerdings geht wohl gar nicht, da jedes Rollo eine andere Laufzeit haben kann.
Scheint ein Dilemma zu sein. Da bleibt wohl nur, die Gruppenschaltung nicht zu nutzen.

[Byte09]

Ich bin natürlich von 100 (geschlossen) auf 80 und dann wieder auf 100 gefahren, so dass die Laufzeit in beiden Fällen nur 20 Prozent sind.
Aber wie gesagt, ist eigentlich momentan zumindest noch nicht schädlich.
Eine Zählung des Tages konnte ich noch nicht beobachten. Kann aber daran liegen, dass vielleicht erst heute Abend gezählt wird, in Abhängigkeit meines Resets.
Der Rest scheint super zu laufen. Bei der Erstnutzung kam eine Perlwarnung, aber das ist ja klar.
Die Differenz ist ja auch nicht kritisch. Bei 45 Tagen geht vielleicht eine Minute an Genauigkeit verloren. Wir brauchen aber gar keine Atomuhr. Ist ja nur eine Ladeerinnerung. Selbst 8 Stunden würden da nicht ins Gewicht fallen. Also mach dir keinen Kopf deswegen.

hi invers ,

ist schon klar, das es jeweils 20 % sind . aber je nach config ist ja die benötigte zeit dafür eine andere . bei mir z.b. dauern ( nach config ) 20 % runter 4,4 sekunden, 20 Prozent hoch dagegen 6,4 sekunden .

Code Auswählen Erweitern

time_to_close 22
   time_to_open 32

.... bei der realen Laufzeit machen sich die Unterschiede halt nicht bemerkbar, da du die laufzeit ja auf eine volle fahrt ( 100 % ) angibst und  in der oberen häfte die unterschiede hoch/runter wohl maginal sind , in der unteren hälfte aber ( je nach grösse des rollos ) erheblich. d.h der rollo fährt die obere hälfte in der regel schneller als die untere , beim oeffnen,- beim schliessen umgekehrt .

hinzu kommt der umstand, dass er beim runterfahren die reale zeit berechnet , vom startbefehl bis zum stoppbefehl , der ja kommt um bei 80 % zu stoppen. Beim dem dann kompletten hochfahren muss das modul aber davon ausgehen , dass ggf gar kein stoppbefehl kommt  ( fährt ja bis zur endposition ) , und zieht daher in diesem fall nur die hinterlegten werte heran ( postition start - position hoch = x% zu fahren  | resultierende Betriebszeit x% der hinterlegten zeit im attribut 'time-to-open' + 1 sekunde reserve )  .

soviel zur theorie . ob ich mich nicht doch verrechnet habe , kann ich erst morgen schauen ,mir hat es heute nacht meine SD Karte des aktivsystems zerschossen und ich muss mich erstamal kümmern, das alles wieder läuft .

.... und annähernd sollte es ja schon passen .

  Gruss Byte09

[Byte09]

Nachtrag:

-  in meinem Testsystem hat er den tag eben hochgezählt
- ja, gruppe 0 hatte ich gestern nicht auf dem schirm.  ändere ich morgen , dass die readings für gruppe 0 nicht angelegt werden . Bei Gruppenfahrten wird aber schon jetzt jedem Device innerhalb der Gruppe die entsprechende (individuelle) laufzeit zugerechnet , es geht nur um die überflüssigen Readings in der Gruppe 0

gruss Byte09

[Invers]

Oh Mann! Da hast du ja jetzt mit der Rücksicherung den Kopf voll. Manchmal kommts dicke.
Ja, danke für die ausführliche Erklärung. Verstanden. Leuchtet ein.
Mit derBerechnung der Gruppenfahrt finde ich cool. War mir nicht bewusst, dass du das mitrechnen kannst für die einzelnen Devices. Finde ich toll, weil du ja irgendwie erst feststellen musst, wieviele Devices jeder hat. Gut, dass das geht.
Dann wäre ja die Sache perfekt, nachdem die Readings gelöscht worden sind.
Bei mir hat er auch um 21:18 hochgezählt. Noch nicht alle, aber das kommt noch (andere Reset-Zeit).

Ja, von mir Daumen hoch und dickes Lob. Mehr kann man an dem Modul wahrscheinlich nicht erweitern/verbessern.

Fettes Dankeschön!!!

[Byte09]

die aktualisierte Version ist ab sofort im SVN und wird mit morgigem Update verteilt.

gruss Byyte09

[Invers]

Hi, ich habe bemerkt, dass das devStateIcon (nur Device 0) nicht mehr aktualisiert wird. Bei allen anderen Devices geht es.
Kannst du da irgendwann bitte nochmal kurz drübergucken?

Die Zählung der Tage und Sekunden funktioniert super. Jetzt sind auch die Werte plausibler. Die Sekunden habe ich allerdings in meiner Readingsgroup gerundet.

Code Auswählen Erweitern

Internals:
   CFGFN     
   CHANNEL    0
   DEF        84314CD0
   ID         84314CD
   IODev      sduino
   NAME       Siro_0
   NR         431
   NTFY_ORDER 50-Siro_0
   STATE      0
   TYPE       Siro
   Version    V 0.48
   state      0
   CODE:
     1          84314CD0
   READINGS:
     2018-01-25 08:14:12   action          no action
     2018-01-28 08:44:03   position        0
     2018-01-28 08:44:03   state           0
   helper:
     MODE       physical
     aktMsg     off 0 1516864451.0341
     lastMsg    off 0 1516864302.48274
     lastProg   0
     lastparse 
     lastparse_stop stop 1509953292.10412
     parse_aborted 0
     position   0
     positiontimer 148.5
Attributes:
   IODev      sduino
   SignalLongStopRepeats 15
   SignalRepeats 8
   cmdIcon    50:rc_RIGHT@gold off:rc_UP@gold on:rc_DOWN@gold stop:rc_STOP@gold
   devStateIcon {return '.*:fts_shutter_'.(int($state/10)*10).'@gold'}
   down_auto_stop 0
   eventMap   /position 50:50/
   invers_position 0
   room       Rollo
   webCmd     stop:on:off:50

Besten Dank im Voraus.