ElabNET Technik Forum

Ahh OK dann mehr sowas wie andere Systeme abfragen, und hier und da aktiv Sachen im TWS bedienen. MAcht Sinn. Kann da nur nicht beurteilen, wie Gleichartig das zu UDP/TCP und MQTT ist.

MQTT --> zukünftig native CV
ZSU --> Grundfunktion (mit Custom-Logik und Cron einfach zu aufwändig)

Gruß
Klaus

Mir fehlen zwei Dinge sehr in der Liste

Systemvariable und Nachrichtenzentrale
Ein Nachrichtenzentrale ohne Systemvariable ist m. E. nur halbsoviel wert.

Ausserdem fehlen mir auch andere Punkte in der Liste, die hier im Forum schon öfter Thema waren und vor allem eine Weiterentwicklung des LE betreffen :
[1]Grafische Aufbereitung des LE (haben sich immer wieder Nutzer gewünscht. Ich selber komme zwar ohne klar, aber ich habe auch ein paar Dinge, die damt wesentlich übersichtlicher sein könnten und ich habe inzwischen NodeRed im Einsatz) -> Anwendungsfall: Komplexe Logiken werden wesentlich Übersichtlicher, Viele Neueinsteiger haben damit schneller Erfolg beim Aufbau Logiken die auf mehrere Module setzen, als mit Custom-Logiekn.
[2] Massenerstellungsoption für Logiken (einfache, textbasierte Option für die automatische Belegung von Ein- und Ausgängen beim Kopieren von Logiken)
[3] Übernahme von mehr Eigenschaften beim Kopieren von Logiken (Beispiel1: Wer eine Beschattungs-Logik angelegt hat, die ja gerne einmal 10 oder mehr Eingangsparameter hat und diese für jede Fassadenseite kopiert, muss dann immer wieder einige gleiche Parameter verschalten. Beispiel 2: Wenn man CustomCode hier postet geht die Information verloren, dass ein Eingang als Parametereingang vorgesehen ist, bei dem es keine Verschaltung braucht.
[...] Das sind teilweise kleinere Dinge, aber es gab hier und da Vorschäge im Forum zur Weietrentwicklung des LE. Daher wäre ein Punkt "Weiterentwicklung des LE in der Liste" gut gewesen. Auch wenn es vielleicht nicht als Number 1 herauskommt.


Abgestimmt habe ich für

1) MQTT(um z. B. Werte für die Visu oder für Nodered aus der Logik Engine ohne KNX (nervige Ets Programmierung) anbinden zu können.
und
2) Szenencontroler (wobei der für mich eigentlich die gleiche Wertigkeit hat wie Alexa) und da ich für Szenencontroller, Alexa, Abwesenheitssimulator, und ein paar andere Dinge ja bereits eine Lösung mit NodeRed habe, habe ich da keine Eile.

Ich habe für MQTT und Alexa gestimmt.

Zu MQTT ist schon vieles gesagt.
Sprachgesteuerte Varianten halten ich strategisch für ganz wichtig , um im normalen Consumer-Bereich neues Kundenklientel zu erreichen.

Die Zukunft der Smart-Home-Steuerung wird m.E. nach eindeutig sprachbasiert sein ..... deshalb finde ich das auch wichtig zeitnah zu implementieren.

Guten Morgen,

vielen lieben Dank für Eure Teilnahme, bitte weiter schreiben, für uns ist das sehr interessant.


Nachrichtenzentrale:

Die Umfragen im Forum sind auf 10 vorgebbare Antworten beschränkt. Eure Beiträge hier dazu werden aber auch gezählt, bitte keine Sorge.

Zur Nachrichtenzentrale gehören auch Systemobjekte und Funktionsparameter wie auch Texte. Wenn man sich die neue Modbus Implementierung ansieht, dann sieht man dort bereits entsprechende Vorbereitungen dafür (In der Wertprüfung und Wertwandelung kann man fast alles auch als String ausgeben lassen, es gibt Statistiken mit Ereignis und Fehlerzählern und es gibt ein angedachtes und in Teilen vorbereitetes System von Fehlermeldungen).

Das Bedeutet, dass die Hauptarbeit der Nachrichtenzentrale nicht das versenden von eMails oder Telegram Nachrichten ist, sondern das Sammeln und Aufbereiten von Daten. Gerade das Aufbereiten ist nicht einfach, weil wenn irgendwo etwas wild läuft, dann will man nicht 1000 Messages am Tag haben, dass die Formel etwas falsch berechnet, sondern eher eine Meldung, wenn es das erste Mal aufgetreten ist und dann eine Meldung wenn es noch zehnmal aufgetreten ist und dann eine wenn es nun hundertmal in der letzten Stunde aufgetreten ist usw. Also eine Bewertung und Filterung mit einem etwas intelligenteren Mechanismus.


lg

Stefan

Hallo,

neben MQTT würde ich auch gerne noch die Verwendung des CAN interfaces (viewtopic.php?f=9&t=614&start=10) in den Ring werfen. Meine WPM bietet CAN und z.Zt. muss ich das noch über einen zusätzlich Raspberry in mein Smart Home einbinden

Hallo Jens,

blaubaerli hat geschrieben: ↑So Mär 21, 2021 7:35 pmin das Leistungsmerkmal "Zeitschaltuhr" sehe ich mal implizit die Kalenderintegration mit integriert. Das wäre für mich einfach prima, weil dann das Auslösen von Aktionen nicht "nur" über Logiken und deren Einstellungen aktiviert werden kann, sondern eben vollintegriert mit einem hohen WAF möglich wird.

gerade die Kalenderintegration macht aus einer einfachen Zeitschaltuhr ein sehr umfassendes Projekt, weil wir haben da schon Dinge animplementiert, wobei das dann auf viele Details ankommt.

Daher bitte: Was sind den die GENAUEN Vorstellung von Kalenderintegration? (welchen? wieviele? wie änderbar)

Um ein Gefühl zu geben:

- EINEN lokal im Timberwolf Server geführten Kalender zur Auswahl unregelmäßiger Termine nur über die Admin-Oberfläche ist halbwegs einfach

- Dagegen wäre die Einbindung mehrerer globale Kalender aus der Cloud (also der oder die Google Kalender der Familienmitglieder) inkl. gegenseitiger Synchronisierung (zwischen TWS <-> Google Cloud), womöglich noch über eine VIsu (Visu <-> TWS <-> Google Cloud) ein nicht finanzierbarer Wunschtraum (nicht finanzierbar deswegen, weil die Kunden den Aufwand dafür nicht bezahlen würden)

==> Daher bitte konkretisierten, was mit "Kalenderintegration" so ganz genau gemeint ist.


Merci

Stefan

StefanW hat geschrieben: ↑Mo Mär 22, 2021 12:04 pm - EINEN lokal im Timberwolf Server geführten Kalender zur Auswahl unregelmäßiger Termine nur über die Admin-Oberfläche ist halbwegs einfach

Also für meine Zwecke ist dieser Kalender im TWS gepflegt, das was ich brauche. Ich möchte da dann Events mit Zeiten eintragen und dann eine Aktion starten.

Cool aber Nive to have wäre wenn man die Termine importieren könnte. Dies sollte sich dann für mich auf https://de.wikipedia.org/wiki/ICalendar bzw. noch https://de.wikipedia.org/wiki/VCalendar beschränken.

Cloud Einbindung oder SYNC mit den diversen Diensten brauche ich da nicht. Das ist alles viel zu komplex und Bedarf meiner Meinung nach zu großen Pflege Bedarf bei Elabnet. Das könnte dann besser in andere Leistungsmerkmal investiert werden.

Hallo zusammen,

dem Wunsch von @Marinux kann ich mich uneingeschränkt anschließen.

Ich bin dafür zunächst den Anschluss von mehr/unterschiedlichen Systemen / Geräten zu forcieren und dann die "logischen" Funktionen auszubauen.
Für den Modbus habt ihr da eine sehr gute Referenz in der Pipeline. Hut ab.

Hallo Markus,

Marinux hat geschrieben: ↑Mo Mär 22, 2021 10:42 amdie Verwendung des CAN interfaces in den Ring werfen. Meine WPM bietet CAN und z.Zt. muss ich das noch über einen zusätzlich Raspberry in mein Smart Home einbinden

Es gibt viel CAN, weil man CAN da sehr viel machen damit. Am Ende funktioniert nur was auf das Bit genau stimmt und deshalb muss man schon GENAU wissen, über was man spricht.

Das gilt für vieles. Nur weil das Gerät XYZ per TCP oder CAN oder RS-232 angebunden ist, sagt das nichts über das Protokoll und die darin enthaltenen Datenformate aus.

Zum Beispiel: MQTT kommuniziert über TCP, Modbus auch (und eigentlich nutzen alle IP-Protokolle UDP oder TCP). Daher kommt es weniger auf den Transportmechanismus an als über das Protokoll. Leider ist damit auch noch nicht alles gesagt, weil Modbus oder MQTT können die enthaltenen Daten praktisch völlig beliebig kodieren. Bei Modbus sind wir auf 5120 Varianten gekommen - und das sind nur die gängigsten Varianten. Ein Bit darin falsch kodiert oder dekodiert, schon geht es nicht. Nur um den Aufwand zu verdeutlichen und die Details die wir berücksichtigen müssen.

Wir können mit dem Budget das wir haben nur generische Anbindungen machen, also das was dann ein Nutzer selbst konfigurieren kann. Eine Unterstützung für ein ganz spezifisches Gerät dürfte nicht finanzierbar sein.

Unsere Empfehlung ist, für spezielle Protokolle zu Gerät XYZ einen Container installieren und dort dann das spezielle Kommunikationsmodul hinzufügen.

Für IP ist das einfacher, bei seriellen Verbindungen wird das schwieriger, aber man kann darüber nachdenken, wie man Schnittstellen zur eigenen Kontrolle im Container frei gibt. Bei CAN ist das allerdings nicht so einfach, weil es nicht DEN EINEN CAN-Kommunikationsstack im Betriebssystem gibt, den alle Applikationen dann nutzen können.


lg

Stefan