FTUI stört den "on-for-timer"

Begonnen von arestant, 29 April 2016, 13:48:48

Vorheriges Thema - Nächstes Thema

arestant

Hallo Zusammen,

ich habe ein Problem, dass ein "on-for-timer" Befehl mit einer sehr kurzen Zeit (0.1 Sekunden), manchmal nicht zu Ende ausgeführt wird.
D.h. der Aktor bleibt dauerhaft im "on" Zustand hängen. Eine größere Zeit 0.3s scheint zu funktionieren

Das passiert in ca 10-20% der Fälle und nur wenn ich über FTUI schalte. Zum Test habe es mit Interface nur mit einem einzelnen Switch ausprobiert.

Ich könnte zwar die Zeit von 0.1s auf 0.3s erhöhen und eine Sicherheitsüberprüfung einbauen mit der Hoffnung, dass es immer funktionieren wird auch mit einem vollgepackten UI. Aber ich muss mir sicher sein, dass der Aktor immer ausgeht und möchte deshalb den Grund verstehen.

Ich setze einen Cubietruck ein der 99% Zeit nix zu tun hat. Aktor ist ein Homematic wired.

Jemand eine Idee?

roman1528

Moin.

Eine Idee habe ich nicht direkt.

100 Millisekunden sind schon verdammt kurz. Kommt da der Aktor bzw. FHEM überhaupt mit?

Was ist wenn du direkt in FHEM (FHEMWEB) diesen Aktor mit on-for-timer 0.1 bedienst... Klappt es dort in 100% der Fällen?

FTUI setzt nämlich nur einen Befehl an FHEM ab. Genau wie wenn du den Aktor in FHEM selbst schalten würdest. Denn für dass OFF ist ebenfalls FHEM zuständig.
Der Aktor an sich kann nämlich kein on-for-timer. FHEM schaltet "on" und nach abgelaufener Zeit wieder "off". on-for-timer ist nur eine Softwareimplementierung.

Ich denke nicht, dass FTUI daran schuld sein wird.

Grüße^^
i3-10305T 4x3GHz;8GB RAM;250GB & 1TB NVMe:
FHEM 6.2;FTUI;8" Tablet's+Fully;NsPanelPro;HUE;ESPRGBWW;HM(CCU3);Duofern; ASC;MQTT(Tasmota);netatmo;SONOS;eBus;DbLog;XiaomiDevice;NUT;ModbusAttr

RPi3+: FHEM 6.2;I²C;GPIO;RFID;G-Tag;XiaomiBTLESens
RPi3: FHEM 6.2;DIY Relais-Board;I²C;GPIO;RFID;Photovoltaik

arestant

#2
Moin,

ja in FHEM Web klappt es in 100% der Fälle. Daher habe ich als erstes eine Vermutung bezüglich FTUI gehabt.

Erklären kann ich es mir nur so, dass FTUI den Cubietruck für ein Augenblick "beschäftigt" der evtl. manchmal länger als 0.1s ist.
Und "on-for-timer" dann irgendwie ein Problem mit der verstrichener Zeit hat.
Das sind natürlich alles Mutmaßungen, daher möchte ich es gerne verstehen um die richtigen Maßnahmen einzuleiten.

Die Zeit ist so kurz, weil ich damit die Stromstoßschalter steuere. Es entspricht etwa der Zeit wenn jemand am Lichttaster kurz drückt.
Beim renovieren hat ein Stück von Putz ein Taster über 1 Tag blockiert. Die Folge war dass das Stromstossrelais kaputt gegangen ist.
Deswegen weiß ich, dass das Relais keine Dauerbetätigung verträgt

Gruß
Paul

roman1528

Ich habe gerade mal etwas die Eltakos studiert XD

Durchschnittsschaltzeiten liegen bei 0,2 bis 0,4 Sekunden... Die ein oder andere Variante brauch sogar einen 0,2 Sekunden Impuls.

Ich denke bei 0,3 Sekunden Schaltzeit kannst du nichts falsch machen.... Dauerstrom dagegen natürlich.. das können die nun wirklich nicht ab.

Ich würde also mal mit 0,2 Sekunden testen und ggf. auch auf 0,3 Sekunden hochgehen^^ Ist ja nun wirklich nicht lange  ;)
i3-10305T 4x3GHz;8GB RAM;250GB & 1TB NVMe:
FHEM 6.2;FTUI;8" Tablet's+Fully;NsPanelPro;HUE;ESPRGBWW;HM(CCU3);Duofern; ASC;MQTT(Tasmota);netatmo;SONOS;eBus;DbLog;XiaomiDevice;NUT;ModbusAttr

RPi3+: FHEM 6.2;I²C;GPIO;RFID;G-Tag;XiaomiBTLESens
RPi3: FHEM 6.2;DIY Relais-Board;I²C;GPIO;RFID;Photovoltaik

StefanD

Selbst 1s wäre, bzw. sollte kein Problem darstellen. Die Stromstoßschalter sind für die Bedienung durch Menschen konstruiert und gebaut und hier ist die Art und Weise der Bedienung nun mal sehr breit gefächert.  ::) ::)

Das on-for-timer wird im Aktor umgesetzt, deshalb ist es eigentlich auch vollkommen egal, ob es vom TabletUI zum FHEM oder in FHEM oder sonstwo zu Verzögerungen bis zum Senden des Befehls zum Aktor kommt. Wichtig ist eigentlich nur, dass der Befehl korrekt am Aktor ankommt.

Ich habe mal testweise auf meiner Testseite meiner neuen FTUI 2.2 Seite meinen Spiel-UP-Schalter mit folgendem Pushbutton gequält:

<div data-type="push"
data-device="test_UPSchalter"
data-set-on="on-for-timer 0.1"
data-doubleclick="0"
class="centered small"></div>


Wenn ich da 10x hintereinander drauf klicke, löst der auch 10x für gefühlt 0,1s aus, jedenfalls sehe ich, dass das daran angesteckte Nachtlicht kurz angeht. Allerdings dauert das abarbeiten der Schaltvorgänge beim schnellen Klicken schon länger, es kommt also auch bei mir zu wahrnehmbaren Verzögerungen in der Umsetzung. Aber wie gesagt, wird alles sauber ausgeführt.

VG Stefan
HW: Intel NUC8i5 mit ESXi7 mit Ubuntu Server 18.04 LTS und FHEM als DockerContainer

roman1528

Zitat von: StefanD am 29 April 2016, 17:52:54
Das on-for-timer wird im Aktor umgesetzt,

Genau das ist eben nicht der fall... diese Umsetzung erfolgt durch FHEM bzw. den Modulen. Der Aktor ist in jedem Fall das was bei arestant auf der Hutschiene (oder sonst wo) hängt  :)

Oder meinst ehrlich dass HM, ELRO, ELTAKO, IT, MyLight und wen es da noch alles gibt einfach so einen FHEM-weit bekannten Befehl unterstützen?
Sie connandRef: on-for-timer gehört zu den sogenannten set-extensions.

Bei on-for-timer sendet FHEM ein "on" an das Gerät/den Aktor und wenn die Zeit abgelaufen ist sendet FHEM ein "off" an das Gerät/den Aktor.

Und da kann ich mir schon vorstellen, dass es bei einer Schaltzeit von 0.1 Sekunden (100 Millisekunden!!!) mal irgendwo haken kann bzw. irgendwer was nicht mitkommt. Gerade auf etwas schwächeren Host-Systemen wie z.B. alten Raspberrys, die eigentlich ausreichend sind.

Also 1 Sekunde ist denke übertrieben...
Wie gesagt. Eltako selber sagt 0,2 bis 0,4 Sekunden wobei die neusten 0-Standby-Relais mindestens 0,2 brauchen um überhaupt zu laufen.
i3-10305T 4x3GHz;8GB RAM;250GB & 1TB NVMe:
FHEM 6.2;FTUI;8" Tablet's+Fully;NsPanelPro;HUE;ESPRGBWW;HM(CCU3);Duofern; ASC;MQTT(Tasmota);netatmo;SONOS;eBus;DbLog;XiaomiDevice;NUT;ModbusAttr

RPi3+: FHEM 6.2;I²C;GPIO;RFID;G-Tag;XiaomiBTLESens
RPi3: FHEM 6.2;DIY Relais-Board;I²C;GPIO;RFID;Photovoltaik

StefanD

Dass 0.1s 100ms sind, ist mir durchaus geläufig, damit bist du nicht allein...  ???

Vielleicht sollte arestant auch einfach mal die genau von ihm verwendeten HM Devices nennen. HM Wired Komponenten gibt es mehr als eines...

VG Stefan
HW: Intel NUC8i5 mit ESXi7 mit Ubuntu Server 18.04 LTS und FHEM als DockerContainer

roman1528

Zitat von: StefanD am 29 April 2016, 19:16:07
Dass 0.1s 100ms sind, ist mir durchaus geläufig, damit bist du nicht allein...  ???

Vielleicht sollte arestant auch einfach mal die genau von ihm verwendeten HM Devices nennen. HM Wired Komponenten gibt es mehr als eines...

VG Stefan

Nicht HM!!! Stromstoßschalter/relais  :)
i3-10305T 4x3GHz;8GB RAM;250GB & 1TB NVMe:
FHEM 6.2;FTUI;8" Tablet's+Fully;NsPanelPro;HUE;ESPRGBWW;HM(CCU3);Duofern; ASC;MQTT(Tasmota);netatmo;SONOS;eBus;DbLog;XiaomiDevice;NUT;ModbusAttr

RPi3+: FHEM 6.2;I²C;GPIO;RFID;G-Tag;XiaomiBTLESens
RPi3: FHEM 6.2;DIY Relais-Board;I²C;GPIO;RFID;Photovoltaik

arestant

Vielen Dank für eure Antworten!

Ich setze auch elektronische Stromstossschalter von Eltako ein. Und diese reagieren bereits mit 100ms.
Wie dem auch sei, ich habe kein Problem mit 300ms. Ich brauche nur sicheres on-off.

Ich werde dann noch ein paar Experimente machen und dann berichten.
Da ich "homematic wired" einsetze (HMW-IO-12-Sw-14-DR) würde ich "on-for-timer" Funktion gegen "on-for-timer" in homematic wireless testen.
Vielleicht liegt das Problem da.

Gruß
Paul

StefanD

Zitat von: roman1528 am 29 April 2016, 19:18:08
Nicht HM!!! Stromstoßschalter/relais  :)

...und die werden aus FHEM via Zauberrei angesprochen?  ::)

Zitat von: arestant am 29 April 2016, 19:19:57
Ich werde dann noch ein paar Experimente machen und dann berichten.
Da ich "homematic wired" einsetze (HMW-IO-12-Sw-14-DR) würde ich "on-for-timer" Funktion gegen "on-for-timer" in homematic wireless testen.
Vielleicht liegt das Problem da.

Viel Erfolg und halte uns auf dem Laufenden. :)
HW: Intel NUC8i5 mit ESXi7 mit Ubuntu Server 18.04 LTS und FHEM als DockerContainer

arestant

Hallo,

heute kam ich endlich dazu meine HW ausgiebig zu testen.
Ich habe es nicht mehr geschafft den Fehler zu reproduzieren.
Sehr merkwürdig...
Ich beobachte dann mal weiter.

Gruß
Paul