Probleme bei DS2408 und schneller Schaltfolge aus STELLMOTOR (V3.0)

Begonnen von sledge, 03 Januar 2019, 19:48:26

Vorheriges Thema - Nächstes Thema

sledge

Hallo zusammen,

habe heute folgendes Setup aus der "dummy + Test-Phase" (wie im Wiki empfohlen) in die Realität geholt (leider bei einem Nachbarn, sodass ich gerade keine Lists zur Verfügung stellen kann):

Mischersteuerung für eine Fußbodenheizung mit PID20 und STELLMOTOR (V3.0). Zur Ansteuerung des Schrittmotors wird ein DS2408 (https://denkovi.com/1-wire-eight-channel-relay-module-for-home-automation-with-din-box) verwendet, der hinter dem Locutus-WLAN Busmaster hängt, welches über das OWX-Modul von pah synchron angebunden ist. Zur Vermeidung von Relais-Fehlern wurde der Schrittmotor gemäß der Schaltung "https://wiki.fhem.de/wiki/Datei:Relais-Schaltung_FBH-Mischer_attr_einzel.jpg" angeschlossen.

Die Ansteuerung via "set <ds2408-device> output channel_auf on" respektive "... off" funktioniert einwandfrei.

Zur Einbindung in den "STELLMOTOR" habe ich die Variante "fhemdev" gewählt und schalte die Ports des DS2408 über NOTIFY via dummy (ein Notify für "... channel auf", ein Notify für ".... channel zu")

Das Problem tritt dei der Ansteuerung durch STELLMOTOR auf - dieser schickt für die Ports "auf" und "zu" des 2408 die Befehle nahezu gleichzeitig los - sodass einer der beiden Befehle verschluckt wird. Das äußert sich so, dass der Mischer zwar problemlos öffnet, aber eine Schließen-Fahrt nicht mehr gestoppt wird.

Dieses "Problem" habe ich durch ein "sleep 1" im NOTIFY für das "... channel auf" gelöst. Leider führt diese Verzögerung (hatte hier 0.5 Sekunde gewählt) dazu, dass der Schrittmotor in realiter immer weiter von der Position laut STELLMOTOR abweicht. Dieser Fehler addiert sich natürlich nach kurzer Zeit zu zweistelligen Prozentpunkten innerhalb der Steuerung auf.

Da ich ein Doppelpost vermeiden wollte, habe ich zuerst mal hier in der 1wire-Gruppe gepostet, da ich gerne herausbekommen möchte, ob es eine Möglichkeit gibt, nahezug "parallel" eintreffende Befehle bestmöglich mit dem DS2408 abzuarbeiten. Eine entsprechende Einstellmöglichkeit im Modul STELLMOTOR habe ich bisher auch nicht gefunden.

Da ich aktuell keinen Zugriff auf den Rechner habe, kann ich auch keine "list device" anbieten, bringe diese aber gerne später bei, falls erforderlich.

Für jegliche Vorschläge / Ansätze dankbar,

Tom

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Haus-Andi

Hallo Tom

Grundsätzlich funktioniert das schon, aber aus eigener Erfahrung muss ich sagen 1-Wire ist nicht sehr schnell für solche Dinge. Irgendwo in diesem Thema gibt es etliche Abhandlungen wie man es besser machen muss. Im Prinzip ist es ganz einfach: du musst immer den HEX-Code (0-255) für alle Ausgänge zusammen senden. Auch da gibt es hier verschiedene Arten wie es gemacht werden sollte. Ich habe genau den selben 8x Relais-Block und habe die gleichen Probleme damit.

Ich habe auch noch nicht begriffen wie ich das anstellen soll, dass fhem zuerst alle Status anschaut und dann die veränderung dazu rechnet und das dann sendet. Ich habe aktuell 4stk Wasserventile für die Gartenbewässerung dran und spätestens beim 3 Ventil hintereinander schalten macht er nicht mehr mit und vergisst oder verliert den Status. Meine Lösung: meiner Frau gesagt sie dürfe immer nur 1stk schalten und dann mindest 30s warten. (ich weiss ist keine Lösung, aber so gehts)

Gruss Andi
Raspberry Pi+Enocen Pi
Thermokon SR04
Micropelt
USB to 1-Wire

cwagner

Meine Erfahrung an dieser Stelle geht noch einen Aspekt weiter: Wenn ich an *zwei* DS2408 direkt hintereinander je *einen* Schaltbefehl als GPIO-Wert sende, geht der zweite mit hoher Wahrscheinlichkeit verloren. Also mache ich zwischen den Set-Befehlen eine Kunstpause von 15 Sekunden.
Das gleich gilt, wenn ich bei einem Denkovi-Multiswitch direkt hintereinander fortlaufend mehrere Channels schalte. Daher mache ich auch dort Pausen. Das auch auf einem System, dessen 1-Wire-Bus 10 cm lang ist und auf dem ausschließlich OWX mit diesem einen Multiswitch lief (sowie ein DOIF, dass die Set-Befehle fortlaufend aufrief).

Bin wie der Thread-Eröffner sehr gespannt, ob es hier aus der Community Hinweise gibt für Lösungsansätze ohne sleeps oder waits (in DOIF) gibt.

Christian
PI 2B+/3B+ Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

Prof. Dr. Peter Henning

Erstens: nicht einzelne Ports on/off setzen, sondern den dezimalen (nicht hexadezimalen) Wert für gpio setzen. Also 255 = alle aus, 0 = alle ein, etc.

Zweitens: Ich wundere mich ein wenig über das "Verlieren" - das kann nämlich nicht sein, weil im asynchronen Modus alle Befehle in eine Queue geschrieben werden. Und immer erst dann, wenn ein Sendebefehl eine Antwort bekommen hat, wird der nächste abgeschickt. Kan es also sein, dass Ihr asynchron=0 gesetzt habt ?

LG

pah

sledge

Ich kann die Erfahrungen von Christian nur unterstreichen. Kommen zwei Kommandos gleichzeitig auf dem 1Wire-Bus zum Denkovi (habe leider keine andere 2408-Hardware hier), gibt es immerhin einen entsprechenden Eintrag im Log

OWXSWITCH_BinValues ds2408.setstate.107: HZ.KG.1WS: invalid data length in setstate, 2 instead of 1 bytes, 0xaa 0xd5

aber wirklich zuverlässig fühlt sich das nicht an - eher wie eine Kollision mit zwei Todesopfern.

Das Symptom des Verhaltens habe ich mit notify und sleep gelöst - im Wesentlichen eine regelmäßige Überprüfung von Soll zu Ist Status der Ausgänge des 2408 und schalte dann entsprechend "nach". Das funktioniert für die nicht zeitkritischen Sachen ganz ok, ist für die Steuerung des Stellmotors aber nur supoptimal. Ich denke hier über eine andere Art der Ansteuerung nach.

Und: Ich bin nicht der Meinung, das 1wire für diese Art der Ansteuerung grundsätzlich zu langsam ist - eine Serialisierung oder Queueing der Kommandos reichte ja vollkommen aus - mich hat die Tatsache einer Kollision und damit der Verlust der betroffenen Kommandos verwundert.

Für mich noch interessant rauszubekommen: Liegt es an der DENKOVI-Hardware, ist es ein generelles 1wire-Thema oder liegt es vielleicht an der Implementierung von OWXSWITCH.

ad 1: Dann hole ich mir was anderes
ad 2: Ich müsste hier über eine andere Art der Ansteuerung nachdenken (Vorschläge gerne willkommen)
ad 3: Currently beyond my skills, aber mit Hilfe machbar...

Danke bisher euch beiden für den Input.

Gruß,

Tom

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

sledge

Zitat von: Prof. Dr. Peter Henning am 12 Januar 2019, 09:53:49
Erstens: nicht einzelne Ports on/off setzen, sondern den dezimalen (nicht hexadezimalen) Wert für gpio setzen. Also 255 = alle aus, 0 = alle ein, etc.

Zweitens: Ich wundere mich ein wenig über das "Verlieren" - das kann nämlich nicht sein, weil im asynchronen Modus alle Befehle in eine Queue geschrieben werden. Und immer erst dann, wenn ein Sendebefehl eine Antwort bekommen hat, wird der nächste abgeschickt. Kan es also sein, dass Ihr asynchron=0 gesetzt habt ?

LG

pah

Hi pah,

Ad 1: wenn die Steuerung über "gpio ..." angeraten ist, muss ich mir noch eine Logik bauen, die den Ist vs Sollstatus "binär" abbildet und den entsprechenden neuen Wert berechnet. Danke für den Hinweis. Aus Gründen der Lesbarkeit und Einfachheit habe ich bisher die einzelnen Ports geschaltet.

Ad 2: Aktuell habe ich "synchron" eingestellt (wie in Prosa auch beschrieben) - stelle ich sofort aber mal um - danke hier für den Hinweis.

Gruß,

Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Prof. Dr. Peter Henning

Was der Denkovi intern macht, kann ich nicht sagen. Mir scheint der Knackpunkt die synchrone Ansteuerung dieses Adapters zu sein.

"Logik"?  Wenn man 8 Stränge (n=1...8) hat, sind die relevanten Zahlen (0=on !!)

254, 253, 251, etc., also immer (255-2^(n-1)) zur einzelnen Ansteuerung des n-ten Strangs.

LG

pah

sledge

Zitat von: Prof. Dr. Peter Henning am 12 Januar 2019, 10:17:42
Was der Denkovi intern macht, kann ich nicht sagen. Mir scheint der Knackpunkt die synchrone Ansteuerung dieses Adapters zu sein.

"Logik"?  Wenn man 8 Stränge (n=1...8) hat, sind die relevanten Zahlen (0=on !!)

254, 253, 251, etc., also immer (255-2^(n-1)) zur einzelnen Ansteuerung des n-ten Strangs.

LG

pah

Naja, das war schon klar. Aber wenn ich von einem zum anderen Schaltzeitpunkt mehrere Channels / outputs auf einmal schalten möchte (so macht es das Stellmotor-Modul), sollte ich den neuen Wert derart berechnen, dass von diesem Schaltvorgang nicht betroffene Channels ihren ursprünglichen Zustand beibehalten. Ein XOR sollte hier den Job erledigen, denke ich.

set gpio 254

setzt ja Channel 1 auf "an", aber alle anderen auf "aus" - und ich will gezielt einzelne Channels an-/ ausschalten können, ohne den Zustand der anderen zu verändern.


Aber erstmal stelle ich jetzt auf Ansteuerung via GPIO um, asnychron habe ich bereits aktiviert.

Danke für den Input.

(Edit: Tippfehler plus "einzelnes Schalten vs gesamt-Schalten" hinzugefügt.)
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Prof. Dr. Peter Henning

Einfach den Code auf dem Modul kopieren, der macht beim Setzen einzelner Channels nichts Anderes.

LG

pah

sledge

Yep - den Code schaue ich mir an.

Ein Problem bleibt aber noch: Trotz Umstellung auf asynchron führen zwei gleichzeitig eintreffende Kommandos dazu, dass beide Kommandos "verschwinden".

Beispiel: Soll der Linkslauf des Mischermotors gestoppt werden, so sendet STELLMOTOR zwei Befehle:
set Mischer <device_für_auf> off; set <device_für_zu off>

Dies stellt sicher, dass bei jedem "STOP" beide Channels "off" sind und somit beim nächsten Einschalten nicht versehentlich beide Ausgänge auf den Mischer mit Strom versorgt werden (unabhängig von der Absicherung via der im WIKI angebotenen Verkabelung).

Ohne die vorher beschriebene Verzögerung kommen beide Befehle "gleichzeitig" an und werden beide nicht ausgeführt - was dazu führt, dass der Mischer unbeirrt weiter schließt. Zur Zeit behelfe ich mir mit einem eher uneleganten notify+sleep.

Daher die Frage: Wie kann ich zwei gleichzeitig eintreffende Kommandos "abfangen" und in ein Kommando umsetzen, um die Kollision zu vermeiden - hierzu Ideen / Denkanstöße?

Gruß,

Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...


sledge

Here we go.

verbose 5 beim 1wire IODev und beim OWXSWITCH-Device.

Hier geht der Befehl an den Stellmotor, von der aktuellen Position auf Position 88 zu fahren:

2019.01.12 11:55:01 4: STELLMOTOR FBH.Mischer Set Target:88 Cmd:-6.8485210779551 RL:L
2019.01.12 11:55:01 4: OWX_Qomplex: Added dev 29F1F91800000017 to queue 1wire context=ds2408.modstate.1.1
2019.01.12 11:55:01 1: OWX_TCP::Query 1wire: Sending out0xe3 0xc5
2019.01.12 11:55:01 5: SW: e3c5
2019.01.12 11:55:02 5: OWX_TCP::Query 1wire: Received 1 of 1 bytes in first attempt and state opened
2019.01.12 11:55:02 1: OWX_TCP::Write Sending out 0xe1 0x55 0x29 0xf1 0xf9 0x18 0x00 0x00 0x00 0x17 0xf0 0x88 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2019.01.12 11:55:02 5: SW: e15529f1f91800000017f08800ffffffffffffffffffffffffffffffffffffffffffff
2019.01.12 11:55:02 1:    queue 1wire contains 1 entries after insertion
2019.01.12 11:55:02 1:     => 29F1F91800000017 context ds2408.modstate.1.1 expecting 22 bytes, active
2019.01.12 11:55:02 1: ----------------------------------------------
2019.01.12 11:55:02 1: OWX_Qomplex: Added dev 29F1F91800000017 to queue 1wire numread=22
2019.01.12 11:55:02 1:    queue 1wire contains 2 entries after insertion
2019.01.12 11:55:02 1:     => 29F1F91800000017 context ds2408.modstate.1.1 expecting 22 bytes, active
2019.01.12 11:55:02 1:     => 29F1F91800000017 context ds2408.modstate.0.0 expecting 22 bytes, waiting


Und rein zeitlich sollte hier der Stop erfolgen, der aber nicht funktioniert hat:

2019.01.12 11:55:12 5: SW: e15529f1f91800000017f08800ffffffffffffffffffffffffffffffffffffffffffff
2019.01.12 11:55:12 1:    queue 1wire contains 1 entries after insertion
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.modstate.0.1 expecting 22 bytes, active
2019.01.12 11:55:12 1: ----------------------------------------------
2019.01.12 11:55:12 1: OWX_Qomplex: Added dev 29F1F91800000017 to queue 1wire numread=22
2019.01.12 11:55:12 1:    queue 1wire contains 2 entries after insertion
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.modstate.0.1 expecting 22 bytes, active
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.modstate.1.1 expecting 22 bytes, waiting
2019.01.12 11:55:12 1: ----------------------------------------------
2019.01.12 11:55:12 4: STELLMOTOR FBH.Mischer Stop Timing Call: stopTime:1547290512.04124 now:1547290512.1804 queue_lastdiff:0.0940276158822549
2019.01.12 11:55:12 1: OWX_TCP::Query 1wire: Sending out0xe3 0xc5
2019.01.12 11:55:12 5: SW: e3c5
2019.01.12 11:55:12 5: OWX_TCP::Query 1wire: Received 1 of 1 bytes in first attempt and state opened
2019.01.12 11:55:12 1: OWXSWITCH_BinValues: called for device HZ.KG.1WS in context ds2408.modstate.0.1 with data 0x55 0x29 0xf1 0xf9 0x18 0x00 0x00 0x00 0x17 0xf0 0x88 0x00 0x6e 0x6e 0xbf 0x00 0x00 0x88 0xff 0xff 0xe9 0xc9
2019.01.12 11:55:12 1: OWXSWITCH_BinValues ds2408.modstate.0.1: HZ.KG.1WS: no error, 0x6e 0x6e 0xbf 0x00 0x00 0x88 0xff 0xff 0xe9 0xc9
2019.01.12 11:55:12 1: OWX_Qomplex: Added dev 29F1F91800000017 to queue 1wire numread=13
2019.01.12 11:55:12 1:    queue 1wire contains 2 entries after insertion
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.modstate.1.1 expecting 22 bytes, waiting
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.setstate.111 expecting 13 bytes, waiting
2019.01.12 11:55:12 1: ----------------------------------------------
2019.01.12 11:55:12 1: OWX_TCP::Query 1wire: Sending out0xe3 0xc5
2019.01.12 11:55:12 5: SW: e3c5
2019.01.12 11:55:12 5: OWX_TCP::Query 1wire: Received 1 of 1 bytes in first attempt and state opened
2019.01.12 11:55:12 1: OWX_TCP::Write Sending out 0xe1 0x55 0x29 0xf1 0xf9 0x18 0x00 0x00 0x00 0x17 0xf0 0x88 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2019.01.12 11:55:12 5: SW: e15529f1f91800000017f08800ffffffffffffffffffffffffffffffffffffffffffff
2019.01.12 11:55:12 1: OWX_TCP::Query 1wire: Sending out0xe3 0xc5
2019.01.12 11:55:12 5: SW: e3c5
2019.01.12 11:55:12 5: OWX_TCP::Query 1wire: Received 1 of 1 bytes in first attempt and state opened
2019.01.12 11:55:12 1: OWXSWITCH_BinValues: called for device HZ.KG.1WS in context ds2408.modstate.1.1 with data 0x55 0x29 0xf1 0xf9 0x18 0x00 0x00 0x00 0x17 0xf0 0x88 0x00 0x6e 0x6e 0xbf 0x00 0x00 0x88 0xff 0xff 0xe9 0xc9
2019.01.12 11:55:12 1: OWXSWITCH_BinValues ds2408.modstate.1.1: HZ.KG.1WS: no error, 0x6e 0x6e 0xbf 0x00 0x00 0x88 0xff 0xff 0xe9 0xc9
2019.01.12 11:55:12 1: OWX_Qomplex: Added dev 29F1F91800000017 to queue 1wire numread=13
2019.01.12 11:55:12 1:    queue 1wire contains 2 entries after insertion
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.setstate.111 expecting 13 bytes, waiting
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.setstate.110 expecting 13 bytes, waiting
2019.01.12 11:55:12 1: ----------------------------------------------
2019.01.12 11:55:12 1: OWX_TCP::Query 1wire: Sending out0xe3 0xc5
2019.01.12 11:55:12 5: SW: e3c5
2019.01.12 11:55:12 5: OWX_TCP::Query 1wire: Received 1 of 1 bytes in first attempt and state opened
2019.01.12 11:55:12 1: OWX_TCP::Write Sending out 0xe1 0x55 0x29 0xf1 0xf9 0x18 0x00 0x00 0x00 0x17 0x5a 0x6f 0x90 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2019.01.12 11:55:12 5: SW: e15529f1f918000000175a6f90ffffffffffffffffffffffffff
2019.01.12 11:55:12 1: OWX_TCP::Query 1wire: Sending out0xe3 0xc5
2019.01.12 11:55:12 5: SW: e3c5
2019.01.12 11:55:12 5: OWX_TCP::Query 1wire: Received 1 of 1 bytes in first attempt and state opened
2019.01.12 11:55:12 1: OWXSWITCH_BinValues: called for device HZ.KG.1WS in context ds2408.setstate.111 with data 0x55 0x29 0xf1 0xf9 0x18 0x00 0x00 0x00 0x17 0x5a 0x6f 0x90 0xaa
2019.01.12 11:55:12 1: OWXSWITCH_BinValues ds2408.setstate.111: HZ.KG.1WS: no error, 0xaa
2019.01.12 11:55:12 1: OWX_Qomplex: Added dev 29F1F91800000017 to queue 1wire numread=22
2019.01.12 11:55:12 1:    queue 1wire contains 2 entries after insertion
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.setstate.110 expecting 13 bytes, waiting
2019.01.12 11:55:12 1:     => 29F1F91800000017 context ds2408.getstate.final expecting 22 bytes, waiting
2019.01.12 11:55:12 1: ----------------------------------------------


Das Log ab Start im Anhang.



FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...