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

[Byte09]

Ich erhalte folgende Meldung und das Rollo fährt nicht auf Pos 50:

Code Auswählen Erweitern

2017.10.23 01:35:20 3: Siro_set: handing over to Siro_Send_Command with following arguments: on 50 0
2017.10.23 01:35:20 2: Siro_sendCommand: execute comand on - sendMsg to HASH(0x439c400) channel 4 -> P72#1000010000110001010011001101010000110011#R9
2017.10.23 01:35:21 1: PERL WARNING: Use of uninitialized value $runningtime in concatenation (.) or string at ./FHEM/98_Siro.pm line 1348.
2017.10.23 01:35:21 1: PERL WARNING: Use of uninitialized value $runningtime in addition (+) at ./FHEM/98_Siro.pm line 1349.
2017.10.23 01:35:21 3: Siro_set: handing over to Siro_Send_Command with following arguments: position 50 0
2017.10.23 01:35:21 1: PERL WARNING: Use of uninitialized value $command in hex at ./FHEM/98_Siro.pm line 332.
2017.10.23 01:35:21 2: Siro_sendCommand: execute comand position - sendMsg to HASH(0x439c400) channel 4 -> P72#1000010000110001010011001101010000000000#R9
2017.10.23 01:35:21 2: Siro_sendCommand: execute comand stop - sendMsg to HASH(0x439c400) channel 4 -> P72#1000010000110001010011001101010001010101#R9
2017.10.23 01:35:28 2: Siro_sendCommand: execute comand stop - sendMsg to HASH(0x439c400) channel 4 -> P72#1000010000110001010011001101010001010101#R9

Ich schalte über ein DOIF 2x aus Sichereitsgründen. Klappt aber trotzdem nicht.
Ich nutze Version 0.44

List vom Device:

Code Auswählen Erweitern

Internals:
   CFGFN
   CHANNEL    14
   DEF        84314CDe
   ID         84314CD
   IODev      sduino
   NAME       Siro_SZR
   NR         452
   STATE      0
   TYPE       Siro
   Version    V 0.44
   state      0
   CODE:
     1          84314CDE
   READINGS:
     2017-10-23 08:00:02   position        0
     2017-10-23 08:00:02   state           0
   helper:
     LastMODE   virtual
     MODE       virtual
     aktMsg     position 0 1508738402.16854
     lastMsg    stop 50 1508715328.80938
     lastProg   0
     lastparse
     lastparse_stop stop 1508708425.39511
     parse_aborted 0
     position   0
     positiontimer 23073.3
Attributes:
   IODev      sduino
   SignalLongStopRepeats 15
   SignalRepeats 9
   channel_send_mode_1 4
   cmdIcon    50:rc_RIGHT off:rc_UP on:rc_DOWN stop:rc_STOP
   comment    Geladen am:
21.10.2017
   debug_mode 0
   devStateIcon {my $icon = ReadingsVal('Siro_SZR','state', 0);$icon = (int($icon/10)*10); return '.*:fts_shutter_'.$icon}
   down_auto_stop 0
   down_limit_mode_1 100
   event-min-interval .*:300
   event-on-change-reading .*
   eventMap   /position 50:50/
   fp_Rollo   602,175,2,rechts Schlafzimmer
   genericDeviceType blind
   invers_position 0
   operation_mode 1
   prog_fav_sequence prog,2,stop,2,stop
   room       Rollo,Schlafzimmer
   time_down_to_favorite 13.5
   time_to_close 17
   time_to_open 18
   webCmd     stop:on:off:50

Hi invers ,

Bin auf der Arbeit und schaue mir das heute abend an . Aber unabhängig von den 2 Fehlermeldungen sendet er sowohl den fahren Befehl,  als auch den stop Befehl.   Wie verhält sich das rollo ? Fährt es gar nicht erst los , oder hält es nur nicht an ?

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

[Byte09]

]

Ich glaube es liegt an dem doppelten doif Aufruf.   Teste mal bitte mit einem doif. Wenn es daran liegt muss ich das abfangen.

Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

[Invers]

Es ist genau anders herum.
Ich habe mit einem Aufruf keinen Erfolg gehabt und habe dann mit 2 Aufrufen probiert. Hatte aber auch keinen Erfolg.

[Byte09]

Es ist genau anders herum.
Ich habe mit einem Aufruf keinen Erfolg gehabt und habe dann mit 2 Aufrufen probiert. Hatte aber auch keinen Erfolg.

Hi Invers,

ich kann das problem bei mir reproduzierren und werde das im Laufe des Abends beheben.

( tritt - vermutlich - seit der Version 0.42 auf und nur im Mode 1 )

Grusss Byte09

[Byte09]

nachtrag:

war leider zu voreilig mit meiner aussage . ich kann es nicht nachstellen.

so sieht das ganze bei mir aus ( verbose 5 )

Code Auswählen Erweitern

2017.10.23 17:23:23 5: Siro_Set: aufgerufen -> cmd -> position args -> position 50 0
2017.10.23 17:23:23 5: Siro_Set:newposstate -> 50
2017.10.23 17:23:23 5: Siro_set: test auf double stop
2017.10.23 17:23:23 5: Siro_set: testprogmode -> 1508772203.13239
2017.10.23 17:23:23 5: Siro_set: lastprogmode -> 0
2017.10.23 17:23:23 5: Siro_set: lastaction -> stop
2017.10.23 17:23:23 5: Siro_set: cmd -> position
2017.10.23 17:23:23 5: Siro_Set: teste autostop: 100 < 100  100 < 100
2017.10.23 17:23:23 5: Siro_Set: nodrive -> false
2017.10.23 17:23:23 5: Siro_Set: direkt positiondrive: -> timing: (8.5 = 50*0.17) -> close runningtime:8.5 - modification in % :50
2017.10.23 17:23:23 5: Siro_Set: direkt positiondrive: -> setting timer to 8.5
2017.10.23 17:23:23 5: Siro_Set: kein stateupdate erfolgt
2017.10.23 17:23:23 3: Siro_set: handing over to Siro_Send_Command with following arguments: on 50 0
2017.10.23 17:23:23 5: Siro_sendCommand: hash -> HASH(0x3a25f70) - 84314CDE -> cmd :on: - args -> on 50 0
2017.10.23 17:23:23 5: Siro_sendCommand: operationmode -> 1
2017.10.23 17:23:23 5: Siro set channel: 4 (0100) for signalesp1
2017.10.23 17:23:23 5: Siro_sendCommand: name -> 84314CDE command->on
2017.10.23 17:23:23 2: Siro_sendCommand: execute comand on - sendMsg to HASH(0x360f438) channel 4 -> P72#1000010000110001010011001101010000110011#R8
2017.10.23 17:23:23 5: Siro_set: runningtime -> 0.0406169891357422

und so läuft es auch .bei dir sind da ein haufen zeilen drinnen, bei denen ich noch überhaupt nicht einordnen kann, wo sie her kommen und die zum teil völlig unsinnig sind : z.B

Code Auswählen Erweitern

017.10.23 01:35:20 3: Siro_set: handing over to Siro_Send_Command with following arguments: on 50 0
...
2017.10.23 01:35:21 2: Siro_sendCommand: execute comand position - sendMsg to HASH(0x439c400) channel 4 -> P72#1000010000110001010011001101010000000000#R9


... die routine Siro_sendCommand dürfte niemals das kommando " position " bekommen , da sollte es nur on , off und stop geben.

hattest du das device bei der umstellung auf v0.42 komplett gelöscht ?

könntest du mir den gleichen log nochmal auf verbose 5 einstellen ? ... und  eine raw - definition des devices wäre super !?

gruss Byte09

[Invers]

Ich war damals nach Anleitung vorgegangen und hatte die Def gersichert, die Devices gelöscht, neu gestartetnach Moduleinspielung und dann mit defmod alles wieder angelegt.

Kann ich aber gerne noch einmal machen.

Mit Verbose 5 mache ich gleich (abends). Dann geht meine Wohnung in den Nachtruhemodus.

[Byte09]

Ich war damals nach Anleitung vorgegangen und hatte die Def gersichert, die Devices gelöscht, neu gestartetnach Moduleinspielung und dann mit defmod alles wieder angelegt.

Kann ich aber gerne noch einmal machen.

Mit Verbose 5 mache ich gleich (abends). Dann geht meine Wohnung in den Nachtruhemodus.

nein, lass erstmal. war ein schuss ins blaue und ich denke nicht das es daher kommt - würde sich im grunde auch anders bemerkbar machen, da er den hash dann nicht finden würde da seit 0.42 der devicepointer anders gesetzt wird.

ok, ich warte auf den LOG 

gruss Byte09

[Invers]

Also wenn ich den Befehl set Siro_SZR 50, dann funktioniert es ja leider immer. Nur innerhalb des DOIF nicht.
Warte mal noch mit der Suche. Ich habe alles noch einmal konfiguriert (geht ja schnell) und warte mal heute Nacht ab. Ich stelle Verbose heute Nacht auf 5 und wir werden morgen sehen, was passiert ist.
Melde mich dann.
Bis dahin danke.

[Byte09]

Also wenn ich den Befehl set Siro_SZR 50, dann funktioniert es ja leider immer. Nur innerhalb des DOIF nicht.
Warte mal noch mit der Suche. Ich habe alles noch einmal konfiguriert (geht ja schnell) und warte mal heute Nacht ab. Ich stelle Verbose heute Nacht auf 5 und wir werden morgen sehen, was passiert ist.
Melde mich dann.
Bis dahin danke.

ok , mache ich .

was ich eben bemerkt habe ist aber folgendes . wenn du das rollo in eine position fährst und während der fahrt erneut eine positionsanfahrt veranlasst wird , ohne die richtung zu wechseln ! , ...  das kann das modul im moment nicht wirklich ab. Mit richtungswechsel ist es kein problem , von daher versuche bitte erstmal den doppelten befehl zu vermeiden.

werde das fixen .

gruss byte09

[Invers]

Dann sollte es vielleicht seit gestern daran liegen. ich werde dann den 2. Befehl entfernen bzw um 20 Sekunden verzögern. Ich hatte ja jetzt nur 2 Sekunden Verzögerung. Dann hat sich da wohl etwas verhakt.
Danke für den Tipp.

[Byte09]

V 0.45 im Anhang

Code Auswählen Erweitern

# 0.45 2017-10-28 Byte fehler bei erneutem Kommando während Positionsanfahrten behoben

gruss Byte09

[Dr. Smag]

V 0.45 im Anhang

Byte09: Vielen Dank für deine schnellen Korrekturen und deinen großartigen Einsatz. Ich werde die Version dieses Wochenende testen.

Damit das Modul nun auch in das FHEM-Repository kommt, brauchen wir auch mal Feedback der User, die dieses Modul schon im Einsatz haben.
Sollten keine größeren Probleme vorkommen, werden wir das Modul in der kommenden Woche offiziell einchecken.

LG

[Invers]

Ich habe das Modul ja auch getestet und aktiv mit 4 Rollos im Einsatz.
Alles funktioniert nun einwandfrei. Die Zuverlässigkeit der Schaltvorgänge könnte besser sein, aber das hat ja nicht das Modul zu verantworten. Ich behelfe mich damit, nach 30 Sekunden alle Befehle erneut zu senden. Seither habe ich Null Probleme. Einzige Ausnahme war das von Byte09 genannte Fehlverhalten bei Positionsfahrt.

Hiermit bedanke ich mich noch einmal für die Programmierung dieses Moduls und den Einsatz von massenweiser Freizeit und Gehirnschmalz.

[Byte09]

....... Die Zuverlässigkeit der Schaltvorgänge könnte besser sein, aber das hat ja nicht das Modul zu verantworten. Ich behelfe mich damit, nach 30 Sekunden alle Befehle erneut zu senden. Seither habe ich Null Probleme. Einzige Ausnahme war das von Byte09 genannte Fehlverhalten bei Positionsfahrt........

hi invers ,

stellt sich aber doch die frage, waraus die unzuverlässigkeit resultiert. wenn im log etwas derartiges ( ab verbose 2 ) auftaucht :

Code Auswählen Erweitern

2017.10.28 14:54:10 2: Siro_sendCommand: execute comand on - sendMsg to HASH(0x334f030) channel 1 -> P72#0101101101000001011100001000000100110011#R8

.. dann ist das signal in jedem fall an den signalduino weitergereicht wurde . Wenn der rollo daraufhin nicht schaltet , liegt es in der tat nicht am modul .

was für eine antenne hast du an dem signalduino ? .... und wo befindet er sich ( eingesperrt im schrank .. neben anderen geräten ) ?
ich nutze eine externe antenne wie diese  ( https://www.ebay.de/i/182243118765?chn=ps&dispItem=1 ), und habe damit keine empfangs oder sendeprobleme, die paar euro habe sich gelohnt .
. Wenn ich es gerade richtig im Kopf habe , kannst du bei dem signalduino die Sendeleistung beeinflussen, hast du sie mal höher gesetzt ?

das genannte fehlverhalten sollte behoben sein.

gruss Byte09

[Invers]

Code Auswählen Erweitern

2017.10.28 14:54:10 2: Siro_sendCommand: execute comand on - sendMsg to HASH(0x334f030) channel 1 -> P72#0101101101000001011100001000000100110011#R8
Ja, diese Kommandos kommen natürlich. Sonst wäre ja alles ganz klar.
Als Antenne habe ich die montierte, die bei der Lieferung von EBay montiert war Den Link hattest du mir ja zur Verfügung gestellt.
Ich denke nicht, dass es an der Sendeleistung liegt. Ich denke, dass irgendwie der Empfänger des Rollos manchmal zu träge sein könnte. An der Aufstellung oder Entfernung zum Rollo kann es nicht liegen. Es ist eine kurze, freie Luftlinie zu überwinden.
Die Sendeleistung höher stellen werde ich mal probieren, weiss aber noch nicht, wie das geht. Muss ich erst im Forum suchen.

Danke für den TRipp.