Status von Aktoren stimmt nicht immer

[Daimler]

Hi,

mir war das ja bisher auch nicht aufgefallen, da ich in der Produktion im Wired Bereich neben dem Eltako-WS überwiegend nur Zustände überwache (Ersatz für TFK und meine Freunde SCI) und da ist selten etwas zur gleichen Millisekunde.

Aber du hast doch wimre einige 2x-Wired Aktoren im Einsatz?
Erstelle eine DV zwischen einem Tastereingang und den beiden Relais des Aktors ohne Delay.
Du wirst feststellen: Der Status stimmt nicht.

Und somit haben wir auf dem Bus letztendlich ein ähnliches Problem wie im Funk: Zeitgleich ist nicht - zum. nicht bei DVs.
Zwar stimmen hier zum. die tatsächlichen Zustände - ich würde aber trotzdem wegen 'Offen Holland' nach Hause flitzen, da mir etwas anderes suggeriert würde.

[creator]

Es besteht ja die Möglichkeit, die DVs durch Programme zu ersetzen.
Damit würde es überhaupt keine Probleme geben. Zumindest was den falschen Status angeht.

Aber ich nutze ja bewusst DVs um zu verhindern, dass man kein Licht mehr einschalten kann sollte die Zentrale mal nicht da sein.

Meine BWMs liegen alle auf dem genannten Schließer Modul. Die laufen auch, wenn man die auf einen Tastereingang legt und dann diesen als Schalter einstellt,
aber dann macht das Stress auf dem Bus.
An das Modul wird maximal alle 10 sek. eine Status Änderung geschickt pro BWM. Weil der BWM nichts kleineres erlaubt.
Das funktioniert eigentlich sehr gut bei mir.

Kann man sich ein Programm schreiben, was den Status der Wired Kanäle prüft und das Ergebnis der CCU mitteilt?

Irgendwie ist das doch echt Enttäuschend! Ich möchte gar nicht an wirklich große Installationen denken mit 20 Rolllädenaktoren + Haufenweise 12/7 Module.

[Daimler]

Ist immer die Frage, wie man die Sache angeht und was man unter 'Smarthome' versteht.
Nach meinem Verständnis sollte alles Notwendige automatisiert laufen - und für Rollos, Beleuchtung etc. benötige ich keine App, WebUi oder was auch immer, um den Status zu sehen - das sieht man dann live.

Sollte man wirklich 20 Rollos und was auch immer über einen Taster per DV bedienen und zusätzlich auch den korrekten Status irgendwo digital sehen wollen - ok, dann setzt man halt einen Delay von 0,x Sekunden.
Das wird den Rollos egal sein und bemerkbar ist das vermutlich für niemanden.

Wie geschrieben, ist mir das noch nie aufgefallen.
Ich habe mich nur zu dem Experiment hinreissen lassen, da es mich interessierte und ich das Ergebnis bei wired nicht erwartet hätte.

[Familienvater]

Hi,

Kann man sich ein Programm schreiben, was den Status der Wired Kanäle prüft

klar, kommt drauf an, was Du nutzt...

In Homematic-Script geht es mit "schlechter" Programmierung (.state() statt .value() nutzen), in HPCL gibt es abfrage(objektname) und ansonsten muss man die entsprechende XMLRPC-Methode getValue bemühen.

Ich bin mir aber gerade unsicher, ob die Antwort vom getValue (egal ob WebUI, HPCL oder sonstwas, die müssen alle im Endeffekt die getValue dafür nutzen) nur an die Logikschicht geht, die angefragt hat, oder ob das global als Event an alle Abonnenten geht.

Wired-Rolläden sind ein anderes Thema, solange jeder Rolladen unterschiedliche Laufzeiten hat, kommt die "Fertig"-Meldung selbst bei gleichzeitigem Start zu unterschiedlichen Zeitpunkten.

Evtl. könnte es helfen, die Ausgänge vom 12/7er "umzurangieren", so das die drei gleichzeitigen Aktionen bewusst auf 3 unterschiedliche Module verteilt wären. Ich meine, so ein RS485-Transceiver prüft den Bus vor dem Senden auf soetwas wie "Kollisionen", aber vielleicht verwechsle ich das auch mit dem guten alten 10MBit-KOAX-Netzwerk...

Der Familienvater

[creator]

In Homematic-Script geht es mit "schlechter" Programmierung (.state() statt .value() nutzen), in HPCL gibt es abfrage(objektname) und ansonsten muss man die entsprechende XMLRPC-Methode getValue bemühen.

Ich bin mir aber gerade unsicher, ob die Antwort vom getValue (egal ob WebUI, HPCL oder sonstwas, die müssen alle im Endeffekt die getValue dafür nutzen) nur an die Logikschicht geht, die angefragt hat, oder ob das global als Event an alle Abonnenten geht.

Ich nutze Yahm und Iobroker.
Die genannten Möglichkeiten liefern aber doch bestimmt alle den Status von der CCU also auch den falschen.
Also es wird nicht direkt das Modul selber nach dem Aktuelle Status gefragt.

Das Problem was ich sehe dabei ist, wenn man eine große Installation besitzt, dann bringt einem das hinterlegen einer Verzögerung überhaupt nichts,
weil man ja gar nicht weis welcher Tastereingang wann getriggert wird und durch was. Bei einer 5 Köpfigen Familie wo dann noch im Anbau die Eltern mit Wohnen,
steigt die Wahrscheinlichkeit immer mehr an so ein Fehler zu verursachen.

Evtl. könnte es helfen, die Ausgänge vom 12/7er "umzurangieren", so das die drei gleichzeitigen Aktionen bewusst auf 3 unterschiedliche Module verteilt wären. Ich meine, so ein RS485-Transceiver prüft den Bus vor dem Senden auf soetwas wie "Kollisionen", aber vielleicht verwechsle ich das auch mit dem guten alten 10MBit-KOAX-Netzwerk...

Das waren noch Zeiten!

[Familienvater]

Hi,

getValue() funkt/telegraphiert explizit das Gerät/den Kanal an, außer es handelt sich um einen Batterie-Sender, der nicht geweckt werden kann (z.B. Temperatursensor).

Das könnte man aber auch mit dem hs485d-Syslog überprüfen, ob eine "Kommunikation" geloggt wird, oder nicht.

Der Familienvater

[creator]

Das könnte man aber auch mit dem hs485d-Syslog überprüfen, ob eine "Kommunikation" geloggt wird, oder nicht.

Ja das ist in den Logs zu erkennen.
Bei 3 Gleichzeitigen Kanälen fehlt immer einer. Der fehlt komplett in den Logs.

Wenn das über getValue() klappt, werde ich mir ein Script Coden welches den Status der Wired Geräte regelmäßig mal prüft.
Hier ist es ja egal da es kein funk ist. Hoffentlich kann ich das in ioBroker mit JS bauen, dann muss ich mich nicht mit der CCU rumärgern

Antwort von eQ-3:

Bei einer Aufteilung würde dies seltener auftreten. Bei sehr großen Installationen könnten aber auch hier Einschränkungen in der Aktualisierung der Zustände entstehen.

Wir empfehlen generell immer eine kleine Zeitverzögerung in den Programmablauf einzubauen, wenn mehrere Aktionen zeitgleich ausgeführt werden sollen.

Somit wird auch die Fehlerquote bei der Abarbeitung in der CCU minimiert wenn die Installationen einen gewissen Umfang übersteigt.

Gefragte hatte ich wie sich das verhält wenn die Kanäle auf mehreren Modulen verteilt sind.
Und bei großen Installationen.

[Tobias78]

Das mit dem regelmäßigen Abfragen des Status habe ich per WebUI Programm schon vor ~ 1 Jahr implementiert. Ist das was ich mit Homöopathie im 1. Post meinte. Gefühlt tritt der Anzeigefehler so weniger oft auf, ganz weg ist der Effekt dadurch leider aber nicht.
Jetzt verstehe ich, warum die neuen Komponenten "IP" heißen. Meines Wissens wird beim "echten" IP Protokoll ja geprüft, ob die Nachricht angekommen ist und sonst erneut gesendet ...
Kann das klassische Wired Protokoll echt so stumpf sein, dass einfach auf den belegten Bus blind gesendet wird?! Wäre eine plausible Erklärung für das beobachtete Verhalten. Offenbar gibt es auch nicht wie bei den Funkkomponenten die Möglichkeit die Anzahl Sendeversuche zu erhöhen. Das klassische Wired wäre so nicht wirklich bidirektional. Eher pseudo-bidirektional ... also nur bei gutem Wetter und wenig Verkehr...
Gruß, Tobias.

[Familienvater]

Hi,

ich glaube IP hat IP im Namen, weil die Adressen der Geräte die gleiche Länge wie IPv6-Adressen haben, sonst dürfte das EQ3-Protokoll eher weniger gemeinsam mit IPv6 haben.

Eigentlich hat auch wired einen Kanal- oder gerätespezifischen Telegramm-Counter, der allerdings schon bei 3 (2 Bit)? überläuft, damit wäre aber auch wired theoretisch in der Lage, eine bzw sogar bis zu drei versumpfte Nachrichten zu erkennen, und entweder eine nachträgliche Kom-Störung zu werfen, oder einfach mal im Hintergrund selbständig die Kanäle des Geräts nach derem aktuellen Zustand zu befragen. Ist halt wieder das Problem des "was ist schlimmer", ein Bus, der wegen pseudo-Komstörungen sich selbst lamlegt, weil er versucht, sich durch requerys zu Heilen, oder das Leben mit einem Status, der ggf. mal nicht stimmt.
Und damit sind wir halb beim Thema:
Was ist mir wichtiger?
Das der Status der Aktoren auf der Zentrale 100% stimmt -> Programme auf der Zentrale erstellen, die auf Tastendrücke entsprechend mit Latenz schalten
Das das Licht 100% zuverlässig auf Tastendruck angeht -> Direkverknüpfungen
Wer beides will, muss ggf. doppelten Aufwand treiben, und sowohl DVs nutzen, und zusätzlich Tastendrücke in der Zentrale reagieren, und die Zustände mit leichter Verzögerung nachprüfen/abfragen, dann sollte die Zentrale immer ein aktuellen Zustand haben.

Wenn EQ3 der Umstand bekannt ist, das gleichzeitige Mehrfachschaltungen innerhalb eines Moduls zum Versagen der Logging-Meldungen führen, dann wäre das ein absolut katastrophales Signal für jegliche Wired-Anwendung, das müsste nämlich mit einem "einfachen" Firmware-Update des Moduls handlebar sein, das die gleichzeitigen Events innerhalb eines Moduls irgendwie in einen Ringbuffer geschrieben werden, der Event für Event nacheinander einzeln gesendet wird, ggf. eben mit Kollisionsprüfung (da im wired-Modul selbst nur eine CPU werkelt, und nicht 12+7 CPUs unabhängig voneinander). Wenn es aber ein grundsätzliches Problem sein sollte, müsste das Forum voll von Problemen mit wired-Aktoren sein, von daher kann es wie immer an irgendwelchen lokalen Gegebenheiten liegen, das es bei den meisten Funktioniert, und bei manchen nicht. Vielleicht ist eine "Verästelung" des Bus ein Grund für solche Probleme, und es sind gar keine Marketing- sondern technische Gründe, warum die wired-UP-Module abgekündigt wurden, vielleicht sind es "falsche Kabel" mit falschen Eigenschaften für diese Art der Signalübertragung, die teilweise eingesetzt werden.

Der Familienvater

[creator]

Ich kann dir nur Beschreiben wie mein Aufbau ist und der ist niedlich finde ich.

NT -> LAN Gateway -> Überspannugsschutz mit Busabschluss- > 12/7 -> 12/7 -> 12/7 -> 12/7 -> 12er Schließerkontakt

Der Bus ist nicht mit Klingeldraht verkabelt, alles mit 0,75mm² ( oder 0,5mm² vergessen! )Flexible mit Aderendhülsen. Bei den Übergängen wurde Doppelhülsen verwendet.
Keine Sternverkabelung für den Bus. Von Anfang bis Ende eine Leitung.
Ich nutze bei den Module auch auf der Ausgangsseite 24V und Schalte damit dann Relais.

Zu den Tastern liegen Eib Leitungen.

Ein Kabel Problem kann ich mir beim Bus eigentlich nicht vorstellen zumindest nicht wenn es schön durchgeschliffen ist.
Ein Kabelbruch bei Klingeldraht würde wohl ein ganz anderes verhalten von sich geben.

Vielen fällt es vermutlich einfach nicht auf, weil Sie ersten keine Visualisierung haben und zweitens das verhalten ja auch nur dann eintritt, wenn eine bestimmte Situation eintritt.
Diese ist ja Abhängig von weiteren Gegebenheiten. Die Wahrscheinlichkeit einen Treffer zu landen ist wohl überschaubar.

Bei mir ist das jetzt aufgetaucht, weil ich es ja durch die gleichzeitige Schaltung von mehrere Kanälen quasi provoziert habe.

Edit:

Das mit dem regelmäßigen Abfragen des Status habe ich per WebUI Programm schon vor ~ 1 Jahr implementiert.

Magst du den Code veröffentlichen?