ElabNET Technik Forum

Ich verweise da mal auf den Threadtitel.

Es geht um die Priorisierung der nächsten Protokolle / Leistungsmerkmale, um dem Server bessere Verkaufszahlen zu bringen.
Die Verbesserungen bestehender Systeme (sofern es keine echten Bugs und Sicherheitsupdates sind) haben da erstmal keine Berechtigung drüber zu diskutieren.

Ich denke kaum das jemand nen TWS kauft weil er nächste Woche den 1-wire 30% schneller pollen kann. Dass das bei bestimmten Busdimensionen eine wünschenswerte Verbesserung ist, kann sich kein Neukunde vorstellen.

MQTT:
Läuft aktuell noch auf nem raspi und sammelt diverse Taster (an beweglichen Möbeln/Gegenständen) über eine sonoff rf-bridge (mit tasmota FW) ein.

Zeitschaltuhr:
Um den WAF zu steigern, wenn die bessere Hälfte einfach Schaltzeiten selbst ändern kann.

gbglace hat geschrieben: ↑Mo Mär 22, 2021 9:37 pm Ich denke kaum das jemand nen TWS kauft weil er nächste Woche den 1-wire 30% schneller pollen kann. Dass das bei bestimmten Busdimensionen eine wünschenswerte Verbesserung ist, kann sich kein Neukunde vorstellen.

Hi Göran,

das Argument wiederum würde ich so nicht stehen lassen. Es kam in letzter Zeit immer öfters vor, dass vom Einsatz von 1-wire eben genau auf Grund des derzeitigen "langsamen" Pollings abgeraten wurde. Und letzten Endes ist 1-Wire nach wie vor einer der mächtigen Verkaufsargumente für den Wolf, aber auch die Sensoren ein vermutlich nicht zu verachtende Einnahmequelle für Elabnet (sodass Stefan selbst schon darum gebeten hat, doch bitte nicht von 1-wire abzuraten).

Du hast vermutlich recht, wenn sich ein Neukunde nur das Datenblatt ansieht und bei 1-wire nen Haken daran macht. Wenn der Kunde sich aber, wie bereits mehrfach geschehen, über die Details mit bestehenden Kunden unterhält, und anschließend auf Grund dieses User Feedbacks im schlimmsten Fall weder 1-wire noch TWS zulegt, dann wäre das sehr unschön.

Wie das ganze am Ende aber zu Gewichten ist, obliegt sicherlich Stefan. Aber es ist ein Thema, das Auswirkung auf den Verkauf haben kann.

VG
Earl

Bitte,

es geht hier AUSSCHLIESSLICH um die Reihenfolgeplanung für NEUE Leistungsmerkmale.

Es geht nicht um die Verbesserung bestehender Leistungsmerkmale. Die bestehenden Wünsche sind alle bekannt und werden berücksichtigt, wenn wir dazu kommen. Der Versuch, bei jeder sich bietenden Gelegenheit immer wieder die gleichen Wünsche zu äußern mag verständlich sein, aber verwässert solche Threads und macht es uns nicht leichter.

==> Daher bitte bei dem gestellten Thema bleiben.

lg

Stefan

Hallo miteinander,

als Einsteiger in die gesamte Smart-Home- bzw. Heimautomatisierungsthematik und als möglichem TWS-Käufer fällt es mir nicht immer leicht zu beurteilen, welche Leistungsmerkmale für mich ganz konkret relevant wären. Derzeit ist halt noch alles in Planung und es ist noch ungewiss, welche spezifischen Geräte letztlich zum Einsatz kommen. Aber ich ordne die Dinge mal ein, wie sie sich mir für den Augenblick darstellen:

Modbus als Server
Apple Homekit ("Siri")

Vollkommen irrelevant für mich. Modbus als Client erfüllt meinen Bedarf.

DMX (als Objektsystem und nutzbar auch mit Desktop-Server)

Wird wahrscheinlich ebenfalls irrelevant sein.

MQTT Client
Timberwolf Lighting Enginge

Könnte interessant sein, insbesondere MQTT. Aber ich weiß zu wenig über konkrete Anwendungsmöglichkeiten von MQTT oder welche Geräte bzw. Services das Protokoll nutzen.

IFTTT Cloudintegration

Könnte interessant sein, da sich viele Dinge über IFTTT anbinden lassen. Die Implementierung vieler Einzelschnittstellen kann so entfallen. Das träfe z.B. auch auf Alexa zu. Auch Kalenderintegrationen (für die ZSU) lassen sich so ggf. leichter lösen.

UDP / TCP
Web-APIs
Zeitschaltuhr (einfach einstellbar)
Amazon Echo ("Alexa")

Das sind die für mich relevantesten Leistungsmerkmale. UDP/TCP ermöglicht die Steuerung so mancher Geräte im Heimelektronik-Bereich, v.a. Mediengeräte. Für den Mainstream-Konsumenten scheint mir das ein sehr gutes Kaufargument zu sein. Die Unterstützung von Alexa schlägt in eine ähnliche Kerbe in Anbetracht der weiten Verbreitung der Amazon-Geräte. Wenn ihr breitere Käuferschichten erreichen wollt, müsst ihr die Realitäten ganz normaler Verbraucher stärker berücksichtigen. Die wollen einfache Anbindungen der Geräte, die sie sowieso schon zu Hause stehen haben.
Viele IFTTT-Anbindungen ließen sich auch über Web-APIs direkt realisieren. Zudem würde eine einfache Unterstützung von Web-APIs viele zusätzliche Services, Websites und Webapps erschließen. Insofern würde ich Web-APIs gegenüber IFTTT präferieren.
Eine einfach zu nutzende ZSU ist eigentlich essenziell. Wichtig wäre v.a., dass auch meine Frau ohne großen Aufwand eine Zeitschaltung realisieren kann, ohne in die Tiefen der Objektverwaltung des TWS eintauchen zu müssen.

Da die ZSU sowieso schon so viele Stimmen bekommen hat (wäre sonst meine Nr. 1) habe ich meine beiden Stimmen UDP/TCP und Amazon Alexa gegeben.

gbglace hat geschrieben: ↑Mo Mär 22, 2021 9:37 pm Es geht um die Priorisierung der nächsten Protokolle / Leistungsmerkmale, um dem Server bessere Verkaufszahlen zu bringen.

Ich finde es super, dass ElabNET so gut mit seinen Kunden kommuniziert und sie in die Weiterentwicklung seiner Produkte einbindet. Aber die Betonung liegt hier auch auf "Kunden" im Sinne von "Bestandskunden". Wenn ich mich nicht irre, sind - abgesehen von mir - alle, die sich hier bislang zu Wort gemeldet haben, Bestandskunden, die schon einen Server haben. Wenn Stefan herausfinden will, was sich potenzielle Kunden wünschen, um bessere Verkaufsargumente für den Server zu generieren, wäre es vielleicht zielführender diese potenziellen Käufer auch zu befragen. Bitte versteht mich nicht falsch. Ich bin froh, dass Kunden eingebunden werden. Aber ich befürchte, dass diese Befragung ein verzerrtes Bild zeichnet, da die Antworten hier hauptsächlich von technisch eher versierten Bestandskunden kommen, statt von Leuten, die - wie ich - vor der Entscheidung stehen, wie sie ihr Smart Home planen und welche Geräte am besten zu ihrem Bedarf und ihrer Lebenswirklichkeit passen. Das ist ein klassischer "customer communication bias" bedingt durch die primären Nutzer dieses Forums. Das heißt natürlich nicht, dass sich die Bedürfnisse von Bestandskunden und potenziellen Käufern nicht decken. Aber ob dem so ist, lässt sich hier schwer rausfinden

Stefan, bitte entschuldige, wenn ich hier zu sehr vom Thema abgekommen bin. Aber ich wünsche Euch einfach noch mehr Erfolg mit Euren Produkten. Schließlich ist ein gesunder Absatz auch in Zukunft ein Garant für guten Kundenservice.

Hi eChris,

Wenn Du noch in der Planung bist dann nimm es als Tipp entgegen, nicht weiter mit IFTTT zu planen. Das ist ein harter Cloudservice. Die haben natürlich zu allen hippen IoT Geschichten einen Adapter, aber jede Logik die man sich da zusammenklickert läuft in der Cloud. Da funktioniert dann schnell mal gar nichts in deinem Haus wenn da irgendwo Schluckauf auf der Leitung ist. Und als Privat-Kunde (mittlerweile ja auch nicht mehr alles kostenlos) bezahlst da mit Deinen Daten. Im Sinne eines sicheren Smart-Homes in meinen Augen vollkommen das Gegenteil dessen was man erreichen will.

Wenn Du nach Adaptern zu IoT suchst schaue Dir sowas wie Node-Red (das mag ich sehr) oder OpenHab oder io-Broker. Wobei ich letzteres nicht so recht verstehe wieso das einige gut finden, da dort immer noch viel zusammen mit Node-Red gebaut wird. das wäre mir dann zu viel Adaptieren in der Kette.
MQTT ist dann einfach ein schnelles Protokoll um von TWS internen Daten an Node-Red zu kommen und das was in MQTT transportiert wird als "Text-Nachrichten" hat schon sehr den Stil dessen was die Umsysteme so hin und her schicken. Somit ist MQTT eine sehr universelles System um z.B. via Node-Red dann alles an IoT anzubinden was der TWS dann noch nicht kann. Und ein NR-Container ist hier im Forum bisher noch nicht als problematisch auffällig geworden. da sind andere Mediatoren auffälliger hier und in anderen Foren.

Ansonsten potentielle Neukunden hier zu haben ist zu selten, das stimmt. Aber offensichtlich nicht unmöglich. Und umso besser das Du hier auch was geschrieben hast.

Zu Mehr Fragen / Antworten in Deinem Planugsszenario gern mehr im eigenen Thread.

Hi Göran,

vielen Dank für die Ausführungen zu MQTT. Wenn MQTT tatsächlich so weitverbreitet ist, klingt das in der Tat nach einem Feature, das jeder gut gebrauchen kann. Insofern würde ich das dann jetzt auch eher als Top-Prio (zusammen mit der ZSU) einordnen. Eine Sache, die ich zu erwähnen vergessen habe, ist die Nachrichtenzentrale. Die stünde bei mir auch ganz weit oben. Hoffentlich kommt die doch noch bald auf die Agenda.

Ich kann Dich übrigens beruhigen. IFTTT spielt für meine Smart-Home-Planung keine (nennenswerte) Rolle. Ich nutze IFTTT derzeit, um Arbeitsabläufe an den Schnittstellen verschiedener Cloud-Services bzw. Web-Apps zu automatisieren. Für das Smart Home wäre IFTTT ggf. ein nützlicher Mehrwert, um die Verbindung zu meinem täglich genutzten Cloud-Stack herzustellen. Aber nichts davon wäre essenziell. Keine Funktion würde tatsächlich von irgendeinem Cloud-Dienst abhängen.

OK zwei Cloud-Dienste kann man auch per Cloud verbinden, aber ich denke der IFTTT nimmt auch ein MQTT Datenpaket als Input an.

Ja Nachrichtenzentrale ist nicht unwichtig. Aber für richtig Mehrwert sind es nicht nur die Nachrichten selbst sondern auch noch einige Basissachen wie System-Objekte selbst damit da auch Futter für Nachrichten hat. Bis dahin baut man sich im LE halt die Alarme und Infosignale die man so braucht und schickt das per MQTT z.B. an Node-Red und dort dann auf Alexa / Telegramm usw.
Daher MQTT als Datenautobahn in die IoT-Welt und danach irgendwann die IoT Systeme selbst nativ anbinden. Der Vorteil bei der Strategie ist. elabnet hat soweit die Entwicklerkapazitäten "frei" um sich auf weitere Funktionen und relativ statische Protokolle zu konzentrieren. Geht man mit knappen Ressourcen direkt auf die IoT-Systeme, dann hast nach einer Handvoll nur noch damit zu tun deren stete sehr kurzfristigen Veränderungen und Weiterentwicklungen nachziehen zu müssen. Gibt nichts schlimmeres wenn wer sagt ich kann Alexa, aber nur den Stand von vor 3 Jahren. Das ist bei DMX / MQTT einfach dankbarer. selbst beim KNX sieht man ja mit Secure auch schon etwas was sich lohnen kann irgendwann nachzulegen.

Ein Aspekt, der mir zur Zeitschaltuhr immer wieder einfällt und ich bin momentan einfach zu unsicher, ob das irgendwo schon mal gesagt wurde:

Viele schreiben hier, dass die ZSU auch von der Frau bzw. der Familie bedienbar sein soll - und so wäre es auch mein Wunsch. Das ist für mich ein Grund, warum ich den am Liebsten in der Visu haben wollen würde und das ist in meinem Fall die CometVisu. Um solche Sachen umzusetzen habe ich mir MQTT als Datenaustauschschnittstelle zwischen TWS und Visu gewünscht. Ich würde meiner Familie ungern Zugriff auf die TWS Oberfläche ermöglichen. Die Visu bedient aber ohnehin Jeder und meines Erachtens gehört die Einstellung einer einfachen ZSU auch sowieso in die Visu.

Moin Zusammen,

Was habe ich gewählt ?

1. MQTT --> Ich habe da einen ESP 32, mit dem will ich spielen.
2. WEB API --> ich will den Speicherladezustand in meiner Steruerung verwenden. Den bekomme ich meines Wissens nur über die WEB API.(Solaredge)