ElabNET Technik Forum

Habe jetzt auch mal wieder Zeit hierauf zu antworten.

Matze76 hat geschrieben: ↑Mi Jan 29, 2020 7:26 pm Das verstehe ich nicht. Wenn du sowieso in beide Themen neu einsteigen müsstest: Warum investierst du die Zeit dann nicht dafür, dich intensiv mit den Logik-Bausteinen und Custom-Logiken zu beschäftigen? Ich habe sogar ohne Elektrotechnik-Studium inzwischen einen ganz ordentlichen Durchblick...

Entweder ich arbeite mich in die Containergeschichte ein, was ich evtl. noch für andere Container benötige, kann aber meine Denkweise, welche ich auch bei der Arbeit nutze beibehalten.
oder
Ich muss mir eine ganz andere herangehensweise zulegen, die mir sonst nirgendwo hilft, da fällt mir die entscheidung leicht.

Habe mir schon die Customlogiken angeguckt und finde es alles andere als übersichtlich, aber das scheint nur meine Meinung zu sein.

Matze76 hat geschrieben: ↑Mi Jan 29, 2020 7:26 pm Gut, das wäre aber dann doch kein Wiregate-Plugin-Ersatz mit all seinen Freiheiten, sondern einfach eine für den Hochsprache-Programmierer bequemere Art eine Custom-Logik zu erstellen. Die Grundsätze des Logik-Editors (keine Sprunganweisungen, keine Schleifen...) würden ja nicht verändert. Ansonsten wäre es nicht "exakt dasselbe".

Das ist doch das, was wir versuchen anzuregen.
@dante damit ist das mit den Schleifen und dem lahmlegen des Servers auch erledigt. Wobei sie manchmal vlt. recht nützlich wären. Mit dem fopen(), wir befinden uns noch in der Logikengine, daher nur Logikelemente.
Der Ansatz mit der Remote-Logik klingt auch sehr geil, dann kann man eben dort nativ schweinereien treiben innerhalb eines Docker-Containers durch Elabnet gestellt und muss sich nicht selber damit herumschlagen...

Dragonos2000 hat geschrieben: ↑Mi Jan 29, 2020 1:51 pm Ich finde den Logikansatz des TWS gut (wenn auch ungewohnt anders). Eine richtige Statemachine fehlt noch (dafür gibt es einen FR), wobei ich mein ursprüngliches Problem für die Statemachine anders lösen konnte.

Ich habe den Satz mal zurückgeholt, wurde ja verschoben ist aber hier besser aufgehoben.

Ja diesen FR gibt es, hat wohl mittlerweile schon schwielen vom rumliegen. Ich weiß dass andere Dinge aktuell wichtiger sind, aber ich hatte nie den Eindruck, dass Stefan auf den Zustandsautomaten groß Lust hat oder dieselbe Begeisterung für aufbringen kann wie die Nutzer hier.
Ich hatte auch noch einen Satz von Stefan im Kopf sinngemäß "Was kann man mit Zustandsautomaten machen was nicht auch mit dem LE geht." Kann ihn aber nicht finden und habe es anscheinend falsch in Erinnerung

Wie schafft es Edomi eigentlich:
- eine Programmiersprache für Custom-Logiken bereitzustellen, ohne dass ich bemerke, dass sich ganz viele aufregen, dass sie gerne etwas anderes hätten
- eine riesige Datenbank an Custom-Logiken bereitzuhalten, ohne dass ich bemerke, dass tausende Edomi Installationen wg. CPU oder Speicherauslastung kaputt gehen.

Sollten die Thesen von @StefanW in viewtopic.php?f=24&t=1910#p21038 stimmen, wäre Edomi voll dem Untergang geweiht, zumal die noch nichtmal bezahlten Support anbieten.
Das Gegenteil ist der Fall.

Was muss also passieren, um eine ähnlich gute Unterstützung von Custom-Logiken zu bekommen, ohne die von StefanW erwähnten Nachteile zu haben?
Welchen geheimen magischen Trick verwendet Edomi?

Ich denke das ist so zu verstehen:
Die Logikengine ist darauf ausgelegt, eingehende Telegramme in wenige ms zu verarbeiten und an den Dispatcher zurückzugeben.
Eine Hochsprache mit Schleifen, fopen, curl etc. passt da nicht dazu.
Aber ich verstehe den Wunsch und hoffe in Hinblick auf schnelles Wachstum der Bausteine auch auf eine Lösung.

Ich denke viele FR (parser, http, etc.) könnte man damit ersetzen, wenn über MQTT o.ä. eine Hochsprache Ansprechbar wäre, die dann Objekte wieder an den Dispatcher zurück gesendet werden könnten:
sendet Anforderung über MQTT, im Docker ein http, fopen, etc. => Rückgabe von Status und Objekt xy...

Lg
Robert

Naja, der „Vorteil“ von Edomi ist, dass nie jemand Geld dafür verlangt hat und somit auch niemand auf die Idee käme, ein Recht auf professionellen support zu haben. Es ist von vorne herein klar, dass der Support im Rahmen der community abläuft und man da keine SLAs oder der gleichen hat.
Und wenn da jemand gerne edomi auf ner 32 bit Plattform laufen lassen will, und der Entwickler sagt „Nö“, dann bleibt mir nix anderes übrig als das zu akzeptieren oder es selber zu machen.

Beim Timberwolf verkauft ElabNET aber die Hard- und Software und gibt Gewährleistung und support darauf. Wenn hier etwas nicht geht wie gewünscht, dann hat man als zahlender Kunde nicht ganz zu unrecht die Erwartungshaltung, dass das gelöst wird, weil es wurde ja Geld bezahlt.

Damit einher geht aber eben wiederum der Anforderung seitens ElabNET an die bereitgestellten Features, dass diese auch mit bezahlbarem Aufwand supportbar sind.

Aber Custom Community Logiken könnten Custom Community Logiken bleiben, für die halt nur die Community Support leistet?
Das könnte ja sehr klar deklariert werden.

Nochmal mal etwas ausgeholt:

Meine These ist:
Der TWS wird nicht darum herum kommen, für Integration von externen Dingen in irgendeiner Weise auf die Community zu setzen. Die Welt da draußen ist zu divers, als das Elabnet mit seinen begrenztem Ressourcen alle wesentlichen Integrationen bereitstellen kann.

Es wäre womöglich günstiger auf eine große Community und ein- bis zwei "Community-Manager" im Support zu setzen, als stattdessen für das gleiche Geld 1,5 Entwickler (+0,5 Support) und alles selber machen wollen.

Aktuell fehlt es ja an einfachen Dingen, selbst E-Mails können wir nicht verschicken. Das Öffnen und Bereitstellen von Custom-Logiken (und Bereitstellen der Basisinfrastruktur dafür) würde bei der aktuell vorhandenen Community rasend schnell viele Lücken schließen.
Selbst die E-Key Anbindung hättet ihr dann womöglich nicht selbst machen müssen und die Energie längst schon wieder woanders hingesteckt.

Oder baut meinetwegen halt einen Node-Red Baustein, der sich mit dem DOS verknüpft und erstellt einen Standard-Container für NodeRed, der dieses Plugin (+MQTT Plugin) sofort installiert hat und ähnlich wie Portainer/Grafana/CometVisu dann Out-Of-The Box funktioniert.
Dazu dann die Knowledge Base mit ein paar Beispielen und Mini-Tutorials ergänzt.

Dann hättet ihr viele Fliegen auf einen Schlag gelöst.

Der Post unter
viewtopic.php?f=24&t=1910#p21038
klingt massiv nach Abschottung zugunsten der Support-Reduzierung. Damit haltet ihr euch doch aber künstlich klein.

Ich denke wenn der TWS nativ MQTT usw. Spricht dann lassen sich viele Fremdsysteme per Nodered und iOBroker nutzbar machen. Ggf ist es wirklich interessant für eine der Systeme Nodered oder ioBroker entweder einen Container oder wenigste s einen leicht bedienbaren Node zu kreieren der sich leicht mit den TWS-Objekten aus der MQTT Schnittstelle bedienen lässt.

EDOMI und Hochsprache Communitybausteine das kann man auf so einem EDOMI Rechner schon tun weil da muss man halt wirklich selber wissen was man da tut. Ich hätte da als Anbieter auch größtmöglichen Respekt davor da das System soweit zu öffnen.

Vergleichbare Situation scheint mir das X1 SDK so man ja drüben im KNX-UF auch Bausteine bauen kann. Keine Ahnung wie das intern geblockt wird oder ob da alles Bausteine durch ein Gira review gehen, das denen die Kiste nicht absäuft.

Wenn Elabnet mit einigen Systemanbietern ein paar relativ exclusive Abkommen hat und entsprechenden Support und Api bekommt ist es ja nicht schlecht sowas direkt quasi nativ bereitzustellen. Ggf auch Mal als zukaufbares Softwarepackage. AberExoten wie von jedem Heizungshersteller quasi ein alternatives KNX-Kopplungsmodul kann keiner Leisten, wäre zwar schön...

Hallo
Warum im Docker Container nicht z.B. ioBroker installieren da gibt es einen Haufen Adapter die niemals für den TWS Entwickeld werden.
Zum Beisp. die Abfrage meiner AI-WP mit Luxtronik1 die Werte kann man auch nach KNX schreiben.
Mit Nodejs kann man auch eigene Scripte schreiben.
Gruß NetFritz

Liebe Foristen,

das ist doch woran wir arbeiten bzw. bereits gearbeitet haben.

1. Ihr habt bereits JETZT die Möglichkeit Docker Container zu installieren und damit auch io:Broker usw.

2. Als Schnittstelle steht hierfür bereits JETZT KNX zur Verfügung

3. Im Laufe des nächsten Quartals (unverbindlich, kein Versprechen) steht zudem auch MQTT integriert im TWS zur Verfügung und dann könnt ihr völlig beliebig und frei- auch quer über jedes LAN und quer über das Internet auf effiziente Weise verknüpfen.

Mehr Freiheit geht gar nicht mehr.

Wir arbeiten genau daran. Damit habt ihr alle Möglichkeiten.

lg

Stefan

Hallo Stefan,
KNX ist mir zu überflutend für den BUS. Aber MQTT sowie der TCP/UDP Sender/ Empfänger sind ja in Entwicklung und wenn das Sauber läuft und das wird es nach der Erfahrung seit der Server eingezogen ist, bin ich wunschlos glücklich und brauche keine Hochsprache im TWS direkt drin.

Nochmal ein großes Lob an alle Beteiligten des Servers für dieses fantastische Gerät und den Support inkl. Der Umsetzung der vielen Kunden Wünsche.