[wiregate] Plugin für intelligente Jalousiesteuerung für dumme Aktoren gesucht...

[netsrac]

Moin Jungs,

gibt es eigentlich ein WireGate Plugin, das etwas mehr intelligenz für dumme Jalousieaktoren anbietet.

Meine Aktoren können nur Auf, Zu und Stop. Leider kann ich weder eine vorgegebene Position anspringen, noch bekomme ich die aktuelle Position geliefert.

Eigentlich müsste man das doch über ein Plugin hinbekommen, was einfach die Fahrtzeiten misst, mit der Gesamtfahrzeit vergleicht, eventuelle "Stops" abfängt und so die aktuelle Position speichert.

Bevor ich mich hier ransetze, wollte ich nur mal fragen, ob es sowas nicht vielleicht schon gibt.

Gruß, Netsrac

[JuMi2006]

Also eine Fahrzeitbestimmung wo es doch mal auf 0,5 - 1,5 Sekunden ankommt mit einem Plugin zu machen halte ich für "mutig".

Workaround wäre ein sichergestellter Reset der Positionierung in den jeweiligen Endlagen.

Grüße

[makki]

Auf einem "leeren" WG würde das gehen, praktisch halte ich es für zumindest problematisch..

Ich bin mit selbigem/ähnlichem auf dem HS (der durchaus Multithreaded ist) vor Jahren kläglich gescheitert..
Fazit: es gibt Sachen die Logik-Engines gut können und andere, wo einfach ein 8-Bit uC mit 1MHz besser ist, Jalousien & Positionieren von Rolläden/Markisen gehört IMHO zu letzterem

Makki

[netsrac]

Fazit: es gibt Sachen die Logik-Engines gut können und andere, wo einfach ein 8-Bit uC mit 1MHz besser ist, Jalousien & Positionieren von Rolläden/Markisen gehört IMHO zu letzterem

Tja...leider kann ich besser programmieren, als ich hardware zusammenlöten kann :-(

Dann schieben wir das Projekt mal in den Ordner "Nächstes Haus".... :-)

[makki]

Na deswegen gibts die Dinger ja fertig zu kaufen
Ehrlich, ich war auch mal so drauf - aber das ist IMHO Zeitverschwendung mit kruder Logik zu versuchen, einen schlechten zu einem vernünftigen Jalousieaktor zu pimpen..
Man kann auch einfach einen neuen kaufen, reinschrauben, alten in die Bucht und sich eine wichtigere Beschäftigung suchen.. Nur meine 5ct..

Makki

[Robert_Mini]

Also ich würde das nicht soooo kritisch sehen (habs allerdings erhrlich gesagt nicht gemacht).
Du sagst ja auf/zu/stop ==> daraus schließe ich mal auf Rolläden. Bei einer Laufzeit von 60-100s und einer ungenauigkeit vom WG von sagen wir mal max. 1 s bedeutet dies eine Abweichung von 1-2%, denke das ist verkraftbar.

Lamellenpositionierung würde ich als kritisch betrachten. Dies ginge IMHO mit dem WG (bei typischen Lamellenverstellzeiten von etwa 1s) nur über sleep für zb 0.6s . Damit werden zwar alle anderen Plugins auch blockiert, dafür werden die 0.6s dann aber recht genau sein zw. Start/stop zur Lammelenverstellung.

Ich verwende das WG zur Auswertung der Impulse von 2 Stromzählern (das können durchaus 1-2 telegramme/s werden), und generiere damit durchaus recht gleichmäßige aktuelle Leistungswerte. Natürlich habe ich damit ein wenig getrickst und sende nur alle 5s einen Wert zurück auf den Bus, zaehle aber Impulse bzw. Zeit richtig. Außerdem habe ich alle Plugins (inzwischen 38 Stk.) so optimiert, dass die Laufzeiten gesichert <1s sind.

Stellt sich nur die Frage, ob Plugins die mit durch eine GA aufgerufenn werden, höher priorisiert sind, als welche die zyklisch aufgrufen werden? Makki?

lg
Robert

[JuMi2006]

Auch wenn ich nicht makki bin, nach jedem Telegramm das empfangen wird passiert folgendes:

Start: max 0.5 Sekunden auf KNX Telegramme warten

1. Prüfen ob ein Sensor angefragt wurde, ggf. Wert zurücksenden
2. Prüfen ob VPN-Freischaltung angefragt wurde, ggf. freischalten
3. Prüfen ob Zeit/Datum angefragt wurde, ggf. Wert zurücksende
4. Prüfen ob ein Plugin-ausgelöst werden soll, ggf. Plugin ausführen

Danach folgt der zyklische Check ob System-RRDs geschrieben werden müssen, Plugins sich verändert haben oder zeitlich an der Reihe sind um ausgeführt zu werden u.s.w.

Jetzt geht es zurück zu Start.

Es gibt da m.M.n. keine wirkliche Priorisierung. Läuft ein Plugin blockiert es den Prozess. Es geht immer fair der Reihe nach.

Grüße

@makki:
Falls das jetzt bullshit ist bitte berichtigen.

[makki]

Soweit alles korrekt

Ich würde es nur etwas anders beschreiben: wenn nichts zu tun ist, wird auf ein Telegramm oder Daten an Sockets gewartet.
- Wenn da was anliegt gehts sofort los
- Wenn nicht wird nach spätestens 500ms geschaut, ob sich ein Plugin geändert hat oder zur zyklischen Ausführung ansteht.
- Alles async, also jeweils mit Queue/Buffer oder wie auch immer man das nennen mag: verpasst wird nichts, aber es läuft eben sequentiell ab.

Zurück zum Thema:
@Robert: Tja, ich habs schon 4x unterschiedlich gemacht und der limitierende Faktor ist nicht die Aufruf/Ausführungsgeschwindigkeit der Plugins Sondern die 100 anderen Stolperfallen - seit meine Rolläden mit Aktor & WS (+minimaler Logik für sperren/zwangsführung usw.) laufen hab ich meine Ruhe.. nur so ein Tipp..

Makki

[Robert_Mini]

Zurück zum Thema:
@Robert: Tja, ich habs schon 4x unterschiedlich gemacht und der limitierende Faktor ist nicht die Aufruf/Ausführungsgeschwindigkeit der Plugins Sondern die 100 anderen Stolperfallen - seit meine Rolläden mit Aktor & WS (+minimaler Logik für sperren/zwangsführung usw.) laufen hab ich meine Ruhe.. nur so ein Tipp..
Makki

Danke. Hab ja selbst auf solch Aktoren gesetzt und damit kein Problem.

Meine obigen "Gedanken" basieren eben nur auf der überaus sehr guten Erfahrung aus den zahlreichen Plugins die ich am laufen habe.
Stolperfallen gibt es sicher genug, aber ist es soooo aussichtslos? naja, Netsrac muss für sich entscheiden...

lg Robert

[makki]

Das klang vielleicht negativ, ich bin nicht aus der Marketing-Abteilung sondern Mitglied im Verein für deutliche Aussprache:
Diese Meinung hat rein garnichts mit WG-Plugins zu tun!
Die werden irgendwann zwischen 2013 und 2023 Multithreaded und dann gibts da keine Latenz mehr. Das ist aber nicht der Punkt.
Ich glaube nur das ich mich mit anderen Systemen, zumindest einem, ähnlich gut auskenne - und da 3x mit ähnlichen Ideen grob auf die Nase gefallen bin.
Das ist aufwändig und führt in den Wald - bestenfalls - per Logik Intelligenz in Jalousieaktoren "nachzurüsten" - das wollte ich sagen..

Makki