Nachträgliche Funktionseinschränkungen von Loxone - das betrifft ALLE Loxone-Kunden

**miqa** · 24.11.2016, 15:03

Vielen Dank schon mal für deine Mühe. Eine Sache müsste in meinen Augen noch ergänzte werden, bzw. geht nicht eindeutig aus dem Schreiben hervor.
Viele hier befürchten ja das Modbus nur der Anfang ist und die anderen Stellen Schnittstellen mittelfristig das gleiche Schicksal ereilt.

**beteigeuze** · 24.11.2016, 15:34

Hallo Freunde,
habe gestern und heute über ein Ticket #678990 Lox mein Problem mit der Abfragezeit 5s erklärt, und dass ich jetzt nicht updaten kann.
Nach anfänglichen allgemeinen nichtssagenden Antworten (incl. der offiziellen Stellungnahme von Hrn. Moser) und freundlichem Nachhaken,
doch eine konkrete Aussage zu machen, hab ich nun auf folgende Frage

S.g. Fa. Loxone,
ich habe einen konkreten Supportfall eingetragen, und Sie antworten mit pauschlaen, verallgemeinernden und bei mir nicht zutreffenden Satatemens und Erklärungen.
Nochmals meine konkrete Frage, dies Sie bitte mit ja oder nein beantworten:
Wird es für mich in Zukunft möglich sein, mit meinem Loxone MS oder Go mit einer aktuellen Config-Version per Modbus TCP im <=1 s Intervall von anderen Geräten Werte abzufragen ?
Bitte um eine konkrete Antwort

diese konkrete Antwort bekommen:

N.N. hat auf Ihr Ticket mit der Nummer [#678990] folgende Antwort geschrieben:
Nein es ist nicht damit zu rechnen, dass dies in Zukunft möglich sein wird.

Damit ist es für mich klar.

Das wars für mich, zumindest für ernsthafte Anwendungen ...
es ist (war) super, mit Euch aus der Community zusammen zu arbeiten. (ich meine hier die le. 2 Jahre, beispielhaft: Chritians Energie und Pioniergeist, Manuels Support, ProfMobi's Programmierkünste, Robins's Pokey's Kompetenz, svethys Qualitätsansatz, manche spitze Feder und Harnäckigkeit und und und ...)

Werde für meinen Fall des Energy - Managements auf ein anderes System (mit starker Community) setzen,
sobald ich mich entschieden habe, geb ich Euch hier im Forum bescheid.

LG Bert

**Christian Fenzl** · 24.11.2016, 16:45

Loxone liest hier schon mit, keine Angst.

Loxone ist zwei Antworten an all ihre Kunden schuldig. Solange das nicht geklärt ist, werde ich nicht nachlaufen mit "Bitte, bitte, lässt mich Lizenzgebühren zahlen!".
Da muss von Loxone auch was kommen.

**Thomas M.** · 24.11.2016, 18:01

Ziffer 1) und 4)
Und "aus sicht der community", "viele aktive aktive user der community" und "die community" kannst durch den Namen des Absenders tauschen.
Wer ist denn die community in diesem speziellen Fall? Der Bruchteil der vielen (aktiven und passiven) ~3000 user die sich wegen dem dermaßen aufregen.

Ich sehe mich auch als Mitglied "der community" und lasse mich nicht da mit reinziehen. Macht unter eurem Namen was ihr wollt, aber nicht als "community".
Wir sind uns untereinander alles mögliche, aber nicht einig.
Es ist schon peinlich genug, wenn von "Verschwörung seitens Loxforum" die Rede ist und nur ein kleiner Bruchteil aller hier etwas damit zu tun hat (und damit nichts zu tun haben will).

Ziffer 4)
Klingt als möchten "viele aktive user" zahlen, dass die 5s wieder auf 0,1s gesenkt werden.
Ein ganz kleiner Bruchteil der aktiven user wollen etwas zahlen.
Die allermeisten eben nicht, weil Loxone unbegrenzt (theoretisch zumindest, alles ist endlich - entweder weil es loxone in 15 Jahren nicht mehr gibt oder weil sich bis dahin so viel geändert hat, dass das dann doch was kostet) lange gratis Loxconfigs anbietet.

Wenn ich was zahle, kaufe ich mir ja kein Recht an einer Schnittstelle oder die Schnittstelle selbst, damit sie ja niemand ändert. Ich kaufe mir die Lizenz zur software oder die software selbst.
Ich kaufe den Miniserver damit auch nicht von technischen Problemen frei.

Wenn Loxone nun angenommen auf die Idee kommt "ok die wollen es so, dann ist loxone eben nicht mehr gratis, Lizenzgebühr = 50€ jährlich", was dann?
Darf euch dann der Großteil der community besuchen und gratulieren, weil jetzt endlich auch alle anderen zahlen dürfen auch wenn möglicherweise genau dieser Fakt (gratis software) eine Entscheidungsgrundlage für Loxone war?

Du kannst freiwillig spenden, soviel du möchtest. Dann nennt sich das aber nicht Lizenzgebühr, sondern bleibt eine Spende.

Ich würde mit solchen Briefleins am Boden bleiben.

**Christian Fenzl** · 24.11.2016, 19:46

Diesmal raunzt Thomas :-)
Und ein monatliches Abo für eine Schnittstellenlizenz hat Pio/Jan natürlich nicht gemeint, sondern eine Dauerlizenz.

Thomas hat wegen "Community" recht, und "Die Community" hat bisher nur Loxone geschrieben.

Pio435 100 aktive Schreiber, und wahrscheinlich viel mehr Leser, warten auf eine Stellungnahme. Es war ja keine Diskussion untereinander, sondern eine Frage an Loxone. Nur weil sich Loxone tot stellt, vergessen die Leute nicht.

So schnell ist das nicht erledigt wie du tust.

lg, Christian

**Automation** · 24.11.2016, 19:47

Ja etwas habe ich noch, das ist zuwenig rausgekommen bei meinem Kommentar.
Eben wer ist denn die Community? Es ist nicht das Loxforum, sondern es sind einige Mitglieder. Ich bitte entsprechend die Formulierung so zu verwenden, dass es aus der wir Sicht "Wir Unterzeichnenden" steht. (Wir sind dann die, die unterschrieben haben). Wie die Unterschriften drauf kommen, kann ich dir auch nicht sagen.

Die Community ist einfach zu pauschal, und es hat mit dem Loxforum nichts zu tun. Wir als Loxforum sind und werden uns neutral verhalten.

**Pio435** · 24.11.2016, 21:10

Also, ich befinde mich nicht im Krieg sondern versuche - und nehme für mich in Anspruch, dass ich das schon immer getan habe - konstruktiv für die Gemeinschaft (alle Kunden) etwas zu erreichen. Dabei gibt es Kunden, die aktuell von den Einschränkungen nichts wissen oder selbst nicht abschätzen können was diese Beschränkungen bedeuten.

Mir liegt fern, für die aktuellen und zukünftigen Loxone-Kunden zusätzliche Kosten zu verursachen für irgendwelche Software-Entwicklungen für die Loxone eigene Hardware. Mit etwas Polemik kann man aber natürlich meine Aussagen in diese Richtung münzen.

Jene, welche wie ich ein Chance in einer Lizenzierung für weitergehende Funktionen sehen, wissen worum es mir geht. Einen weiterhin offenen MS mit möglichst unbegrenzten Schnittstellen. Das möchte ich, weil ich der Meinung bin, dass aktuell kein Anbieter ein ähnliches gutes Produkt mit ansprechender Visu und einfach zu programmierender Logik hat. Fakt bleibt aber, dass diese Offenheit des MS in direkter Konkurrenz zu den Loxone-Produkten steht, welche eben auch die Config mitfinanzieren.

Was liegt denn da also näher, als den MS quasi in Loxone-Eigene Hardware und erweiterte Softwaremodule zu unterteilen und die weiteren Softwaremodule zu lizenzieren, damit eben auch diese Schnittstellen Ihren Beitrag an die Entwicklung leisten. Da spricht niemand von monatlich oder jährlich wiederkehrender Lizenz, sondern von einmaliger Freischaltung. Wie man dann eben eine Modbus-Extension kauft, kauft man sich die KNX-Jalousie-Lizenz, damit bei Jalousieautomatik auch die KNX-Eingänge mit angezeigt werden. Oder die 1-wire+-Lizenz, mit welcher auch andere 1-wire Geräte betreiben werden können, etc., etc. Modular und jeder nur das was er braucht.

Mit einem solchen Modell bin ich der Überzeugung, dass eine win/win Situation geschaffen werden kann, welche dem MS eine effektive Alleinmarktstellung bringt, von der jeder Kunde profitieren kann. Aktuell ist Loxone - natürlich wieder nur meine Sicht - in einer völlig anderen Richtung unterwegs, was eben mittel- bis langfristig Kunden treffen wird, die nicht zu 100% auf Loxone-Hardware gesetzt haben. Übel an der aktuellen Situation ist, das mit der Modbus-Anpassung diesmal sogar eine loxone eigene Schnittstelle angetastet wurde. Denkt man diesen Ansatz konsequent weiter, könnten als nächstes die http/udp Schnittstellen unters Messer kommen. Pokeys werden ja teilweise auch über UDP betrieben - wenn ich das richtig gelesen habe. Warum sollte das ein MS besser verkraften können ...

Anyway, wenn ich hier mit meinen Formulierungen für die Community über das Ziel hinausgeschossen bin, tut mir das leid, und ich nehme hiermit Abstand von einer Publikation im Namen der Community.

Im eigenen Namen erlaube ich mir aber hier nochmals den Aufruf an Loxone:

- Überdenkt Eure Philosophie bezüglich der Schnittstellen. Geht neue Wege um Euer heute immer noch gutes Produkt weider zu dem zu machen, was es zu Beginn war:

Ein mächtiges Tool für die Hausautomation mit praktisch unbegrenzten Möglichkeiten.

Eure grössten Kritiker hier sind wahrscheinlich auch oftmals Eure grössten Fans. Wäre das nicht so, würden wir uns hier nicht so einsetzen - Sorry ich verfalle wieder ins alte Muster - würde ich mich hier nicht so einsetzen!

**Gast** · 24.11.2016, 21:26

Hallo Zusammen,

ich hoffe ich ziehe mir jetzt einiges an Unmut zu.
Dieser post richtet sich NICHT an alle - DIE, die es betrifft werden es verstehen.

Eure technischen Sachverhalte sind und waren NIE die Teil der Sache.
Das haben einige gemerkt und einige nicht.
Die Verschwörung und der Betrug ging von Loxone aus.
Wer agiert sollte mit einer Reaktion rechnen und es nicht shit-storm nennen.

Ich will nicht verstehen wie hier einige Benutzer und einige Partner dass mit sich machen lassen!
Ich will auch nicht verstehen wieso man sich als Partner nicht klar äußern möchte, das muss nichts öffentliches sein.
Aber mal wirklich unter uns, Ihr seid doch bitte nicht der Meinung das sowas ok ist?
Jeder hat doch zumindest ein angeboreneres Unrechtsbewusstsein?

Zahlt schön eure Lizenzgebühren und gebt Euch mäßig.
Wenn mir jemand etwas wegnimmt was eigentlich "mir gehört" werde ich stinksauer.
Mittlerweile erkenne ich das dass Unternehmerische- Risiko schön auf die Partner abgewälzt wird.
Jeder Unternehmer der Loxone Produktiv einsetzt, ist nach all der Erfahrung die ich mit dieser Firma
und deren Politik gemacht habe, meiner Meinung nach (gelinde gesagt) naiv.

Das meine Meinung und meine Posts in Euren Augen nichts bringen oder kontraproduktiv sind
bestärkt mich nur in meiner Ansicht das Ihr kein Rückgrat habt.

Ich bin froh niemals alles auf eine Karte gesetzt zu haben und noch Optionen frei habe.
Ich verstehe jeden der zugibt, das er sich derzeit dazu keine Meinung erlauben kann
und möchte deren meine Hochachtung ausdrücken!

Nun löscht mich, sperrt mich oder feuert dagegen.
Das Schicksal setzt den Hobel an und hobelt alle gleich

Grüße
Christian

**telefonjoker** · 24.11.2016, 23:00

Frage an Loxone-Partner und die, die Loxone-Schulungen besucht haben.

Wurde in den Schulungen seitens Loxone die Problematik mit Modbus nicht angesprochen?

Grüße

Claus

**janralf** · 24.11.2016, 23:40

Ich bin selbst Loxone Partner und kann den Ärger schon verstehen allerdings besteht für Loxone das Problem nicht wirklich. Man will seitens Loxone eigene Hardware verkaufen diese arbeitet nicht mit den offenen Schnittstellen sondern mit Eigenen Entwicklungen z.B. Tree oder Air. In den Schulungen wird über Sonderlösungen garnicht gesprochen.

**svethi** · 25.11.2016, 13:59

Hi Community, Hi harter Modbuskern,

für meinen Teil schwingen hier noch immer zu viele Emotionen mit. Das Thema ist schwierig und polarisiert. Doch dieser emotionsgeladene Aktionismus macht hier alles noch viel schlimmer. Überlegt doch mal weiter. Loxone schreibt bei Facebook, dass die Community nur aus Spinner besteht und Leute, die sich denken, da wollen wir doch mal in die Community reinsehen und sehen was so so los ist. Dann kommen die hier her und sehen, dass sich die Leute hier immer weiter hochschaukeln und zerfleischen. Da kann doch nur der Eindruck entstehen, dass Loxone Recht hat und hier nur eine Horde Barbaren unterwegs ist. Das will doch hier keiner und wird der Community auch in keiner Weise gerecht. Loxone hat ganz klar geäußert, dass sich daran nichts mehr ändert. Aus diesem Grund muss jetzt hier auch nichts übers Knie gebrochen werden. So lange sich hier jeder gleich angefasst fühlt, kommen wir ner Lösung nicht näher. Ich halte es für sinnvoller die Diskusionen hier erst einmal einzufrieren und wirklich ein paar Tage Ruhe einkehren zu lassen. Auch würde ich es sinnvoller erachten, wenn sich der "harte Kern der Betroffenen" im Hintergund zusammenrauft und Ihren Standpunkt und eventuelle Lösungsvorschläge zusammenträgt.
Wenn man dies hier öffentlich mit allen erdenklichen Ideen macht, sieht man ja, was dabei heraus kommt.

Lasst das Thema bitte wirklich erst einmal sacken, wir kommen sonst hier nicht weiter.
Denn eins ist ja wohl klar, viele hier haben in den MiniServer viel Herzblut gesteckt und dass will man nicht einfach so aufgeben.

Gruß Sven

**Jan W.** · 25.11.2016, 14:15

allerdings verwende ich auch keine Bastellösungen

Das Wort "Bastler" bzw. "Bastellösung" kann ich mittlerweile auch nicht mehr hören. Meine SD-Karte hält seit 2 Jahren durch, OBWOHL ich meine Lüftungsanlage (Helios) per Modbus/TCP über den MS steuere. Es läuft auch superstabil. Leider (oder zum Glück ?) musste ich dafür aufwändig per Pico C Programm die Ansteuerung vornehmen, da Helios die Zahlenwerte als Strings erwartet. Auf die Anfrage bei Loxone per Ticket kam folgende Antwort: "Sie können derartiges evtl. mit einem PicoC Programm lösen. Hierbei können wir Sie jedoch nicht unterstützen! Es ist auch nicht angedacht ähnliches in der Zukunft zu unterstützen!".

Ich denke, dass ich nicht der einzige bin, der ein ähnliches Problem hatte, für das nur eine "Bastellösung" gab oder gibt. Macht es einen Unterschied, ob ich das selbst mache oder teuer von einem Loxone Partner kaufe? Der kann es auch nicht besser/anders machen. Soll ich lieber alte Modelle kaufen, wo es beim Beispiel der Lüftungsanlage noch einen 3-stufigen Schalter gab, den man prima mit digitale Ausgängen von Loxone Extensions ansteuern konnte? IoT ist wohl auch ein Begriff, der in Kollerschlag noch nicht angekommen ist. In der Zukunft werden mehr und mehr Geräte direkt per IP angesteuert werden können und nicht mehr per digitalen oder analogen I/Os.

Dass in den Schulungen nur eigenen Produkte von Loxone besprochen werden, ist naheliegend. Es gibt aber in einem Haus häufig mehr anzusteuern, als nur Licht, Steckdosen, Rolläden, etc. Für viele Produkte ist es üblich, dass Schulungen eher für Einsteiger ausgelegt sind, als Expertenthemen zu behandeln. Das ist ja auch o.k., aber ohne eine Community und das Wiki wäre es für viele Kunden gar nicht möglich und für Partner zumindest nicht wirtschaftlich, Anbindungen für andere Systeme mit Loxone herzustellen bzw. anzubieten. Loxone sollte eigentlich froh sein, dass es Anwender gibt, die ihre Lösungen kostenlos zur Verfügung stellen und nicht abfällig von "Bastelllösungen" sprechen, nur weil dort auch der Anschluss eines billigen I/O Moduls erläutert wird, der den Umsatz von Loxone gefährdet. Es ist ja legitim und nachvollziehbar, gegen solche Produkte eine Strategie zu entwickeln, aber dann bitte nicht so plump wie bei Modbus/TCP, wo auch Anwender betroffen sind, die EIN Gerät über die Schnittstelle steuern. Der Vorwand der Last und Stabilität ist nicht glaubwürdig, denn ein Gerät mit einem Abfrageintervall von 0,1 sek erzeugt viel weniger Last, als 100 Geräte mit 5 sek. Das hätte man auch "smarter" lösen können!

Ohne Integration ein EIN System, welches zentral zumindest übergeordnete Steuerungsfunktionen vornimmt, wird ein Haus nicht wirklich "smart". Will ich wirklich die Lüftung oder Heizung über deren Webinterfaces steuern (eine App gibt's da noch nicht einmal)? Nein, ich will das nicht. Ich will auch nicht 10 Apps verwenden.

Zuerst wirbt Loxone mit offenen Schnittstellen und wenn man diese nutzt, dann wird seitens Loxone von Missbrauch gesprochen und man fühlt sich fast kriminell. Muss ich jetzt befürchten, dass Pico C ebenfalls auf 5 Sek. beschränkt wird, weil ich es für Modbus/TCP verwende? Dann wird auch noch das Wort "Verschwörung" seitens Loxone verwendet, auch wenn dies mittlerweile deutlich abgeschwächt wurde. Hey Loxone, ich habe weder ein Facebook Account noch ein Pokey Modul! Die Hoffnung, dass Loxone DAS System wird, mit dem alles integriert werden kann, habe ich nach den letzten Statements begraben. Vertrauen in die Aussagen der Firma habe ich mittlerweile auch nicht mehr, denn man sieht ja, wie schnell die revidiert werden. Wenn es dann auch noch so plump gemacht wird, dass nur die deutsche Webseite angepasst wird (Beispiel Abfrageintervall von 100ms für Modbus Extension), aber nicht die französische oder spanische, dann kann ich da nur mit dem Kopf schütteln. Warum hat man die Extension eigentlich beschnitten?

Insgesamt bin ich enttäuscht von Loxone, aber nicht wütend und werde mein System sicherlich nicht austauschen. Mal abwarten, ob die offenen Schnittstellen wie KNX weiterhin unterstützt werden, wenn der Verkauf von Tree sich nicht im Sinne von Loxone entwickelt? Der Markt im IT-Bereich ist schnelllebig und es sind bereits einige ganz große Riesen Pleite gegangen, weil sie die Zeichen der Zeit nicht erkannt haben. Das wünsche ich Loxone nicht, aber die klare Empfehlung im Bekanntenkreis für das System werde (leider) nicht mehr geben.

**Prof.Mobilux** · 25.11.2016, 14:22

Jan W. Rein aus Interesse: Ich selbst verwende kein Modbus, aber habe ich das richtig verstanden? Die "offizielle" Modbus/TCP-Schnittstelle ist von Loxone auf minimal 5 Sekunden kastriert worden. Du hast Modbus/TCP über PicoC realisiert ohne das es da Beschränkungren gibt? Könnte man damit also, natürlich nur rein theoretisch, auch diese Pokeys & Co mit Deiner PicoC-Lösung anbinden?

**Benjamin Jobst** · 27.11.2016, 20:24

1. Stein des Anstoßes war die Modbus-Schnittstelle. In unserem Fall setzen wir sehr häufig Modbus/TCP ein, um Loxone als zentrale Steuerung auch als Energiemanagement des Gebäudes zu verwenden. Über diese standardisierte Schnittstelle rufen wir die aktuellen Daten zum energetischen Zustand des Gebäudes aus den diversen Geräten ab, verknüpfen die Daten und geben entsprechende Befehle nach außen. Zusätzlich gehört es ebenfalls zu einem guten Energiemanagement, den User über die Energieflüsse im Gebäude informieren zu können – das wurde durch den neuen Energiemonitor ja hervorragend um die Batterie erweitert.

Beim elektrischen Energiesystem rufen wir dabei bisher im Zyklus von 2 Sekunden bis zu 6 Geräte mit jeweils 3-5 Datenpunkten ab. Diese Zeit wurde bewusst so gewählt (auch 1s war häufig gefordert), damit der Kunde einen sofortigen Überblick über seine Energieflüsse bekommt. Eine Verzögerung auf 5 Sekunden ist deutlich spürbar und deshalb eine eindeutige Verschlechterung im Handling des Energiemanagements.

Dazu kommt, dass es angedacht ist, einige Komponenten zur energetischen Optimierung auch in Echtzeit mit den tatsächlichen Leistungen am Netzanschlusspunkt zu steuern – Stichpunkt Heizstab oder Inverter-Wärmepumpe. In diesem Fall müssen die Echtzeit-Daten tatsächlich mindestens jede Sekunde zur Verfügung stehen, damit das System sinnvoll arbeiten kann. Die hier jetzt angesetzten 5 Sekunden sind in diesem Fall absolut nicht tragbar.
Aus technischer Sicht können wir die Einschränkungen wie bereits erläutert nicht nachvollziehen. Die Modbus/TCP-Schnittstelle ist äußerst leistungsfähig und sehr Dateneffizient verglichen mit vielen anderen Datenschnittstellen. Es handelt sich um einen Industriestandard, mit dem noch ganz andere zeitkritische Echtzeit-Systeme geregelt werden. Selbst mit einem Abfragezyklus von 0,5 Sekunden liefen Teststellungen bei uns problemlos, eine Anlage mit mehreren Modbus/TCP-Geräten wird seit fast zwei Jahren mit einem Abfragezyklus von 1s ohne jegliche Einschränkungen von einem Loxone Miniserver „betreut“. Deshalb ist mir der unglaubliche Sprung um den Faktor 50 absolut unerklärlich.
Wo ich bei Loxone allerdings Schwächen bei Modbus/TCP sehe, ist die ineffiziente Abfrage der Daten. Denn Ihr System erstellt für jedes Datenregister, das abgefragt werden soll, eine komplett neue TCP-Verbindung inkl. Request, Handshake und so weiter. Der gewöhnliche Weg ist es eigentlich, über eine Anfrage gleich mehrere zusammenhängende Register abzufragen – manche Systeme erstellen anhand der eingestellten Datenpunkte selbst eine Liste mit Multi-Datenabfragen.
Dass der von Ihnen gewählte „einfache Weg“ mit einzelabfragen eine höhere Datenbelastung für Netzwerk, Modbus-Gerät und Loxone darstellt, kann ich aufgrund des deutlich höheren Overheads durchaus verstehen. Allerdings ist auch das lächerlich angesichts all der anderen Daten, die über das Netzwerk laufen und keine Rechtfertigung für eine Abfrage nur alle 5 Sekunden.

Damit wir mit der Modbus/TCP-Schnittstelle zuverlässig arbeiten können, ist eine Abfrage im Sekundentakt notwendig. Auch wenn ich mir Ihre technischen Einwände ansehe, sollte diese Zeit problemlos machbar sein. Notfalls wäre es vielleicht auch eine Idee, die Anzahl der Abfragen pro Sekunde für alle Modbus/TCP-Geräte zusammengefasst einzuschränken. Bei einer offenen Industriestandard-Schnittstelle sind die 5 Sekunden jedenfalls unangebracht.

2. Die KNX-Schnittstelle ist in meinen Augen eine viel massivere Fehlerursache als Modbus. Denn dadurch, dass Sie weder eine zertifizierte Schnittstelle anbieten noch für die grundlegenden Bausteine hinreichend funktionsfähige Bausteine bereitstellen, provozieren Sie bei jedem eine unglaubliche Bastelei, der Loxone in Kombination mit KNX einsetzen will. Wenn Sie einmal versuchen würden, einen KNX-Raumtemperaturregler (z.B. Gira Tastsensor 3Plus) oder eine KNX-Jalousie irgendwie in Loxone einzubinden, würden Sie die KNX-Schnittstelle so nicht mehr bewerben. Und wir tun das tagtäglich beim Endkunden, weil wir hier teils auf bestehende KNX-Systeme Loxone als Visualisierung aufsetzen.

Ende vom Lied sind teilweise wilde Kombinationen von Workarounds, um z.B. die Automatikjalousie mit KNX zu verwirklichen, dass der Kunde die Jalousie am Ende auch noch bedienen kann. Das kann doch nicht Ihr Ernst sein! Teils erzeugt der Miniserver bei einem Neustart dann so viele abstruse Gruppenadressen, dass sich manche KNX-Aktoren aufhängen und über die ETS erst neu eingeladen werden müssen.

Unser Wunsch hier wäre, dass Loxone sich einmal Gedanken macht, ob man jetzt noch den weltweit anerkannten Gebäude-Standard KNX unterstützen oder komplett auf seine selbst gebastelte Bus- und Funklösung als vollständig proprietäres System setzen will. So halbherzig, wie es derzeit mit KNX läuft, kann es jedenfalls nicht weitergehen.
Wenn Sie sich bereiterklären, den größten Gebäude-Standard KNX weiter unterstützen zu wollen, muss eine bessere Integration für die vier Basis-Funktionen Schalten, Dimmen, Heizen und Jalousie her. Dazu sollte auch die Integration der Automatikjalousie gehören.
Wenn KNX von Loxone nicht gewünscht ist, werden wir uns für diese Projekte nach anderen Visualisierungen umsehen müssen, es gibt zahlreiche ambitionierte Hersteller in diesem Gebiet.

3. Der aktuelle Verbrauch der SD-Karten durch den Miniserver ist nicht akzeptabel. Dazu habe ich bereits ein sehr intensives Ticket mit Ihrem Support geführt. Einige Systeme liefen drei Monate, bis die erste Karte den Geist aufgegeben hat – und das mit 6 Statistiken im 10-Minuten-Takt. Wenn das schon zu viele Daten für die Karte sein sollten, frage ich mich, weshalb man überhaupt die Statistik-Funktion anbietet. Bei einigen Systemen wurde uns umgehend eine neue Karte zugeschickt, was ich Ihrem Support hoch anrechne. Ich muss zugeben, die SD-Karten zu Ihnen einzuschicken, ist noch ein offener Punkt meinerseits, den ich dringend erledigen müsste.

Allerdings kann es nicht sein, dass das gesamte System unserer Kunden alle 1-2 Jahre unbrauchbar wird, weil die SD-Karte den Geist aufgibt. Setzt man vollständig auf Loxone als Smart Home bedeutet das ein kaltes, dunkles Haus ohne Jalousien, bis wir als Notdienst das System wieder zum Laufen bekommen. Und dann ist ein Großteil der Konfiguration (Schaltuhren, Radio-Buttons, Virtuelle Eingänge) sowie alle Statistiken seit der letzten Sicherung verschwunden.
Und angesichts der hervorragend gewählten Lage des SD-Kartenslots können wir dem Endkunden eine solche Bastelei inkl. Aus- und Einbau des Miniserver im Elektro-Verteiler nicht zumuten.

Vom Support wurde mir mitgeteilt, Sie arbeiten an der Thematik und die 4GB-Karten seien schon industrielle SD-Karten – was die Situation angesichts des derzeitigen Verschleißes nicht wirklich besser dastehen lässt. Wir unsererseits setzen jetzt bei jedem unserer Kunden spezielle industrielle SLC-Karten ein in der Hoffnung, das System überlebt so mehrere Jahre ohne Störung. Dies bedeutet zusätzliche Kosten und zusätzlichen Aufwand für uns, den wir gerne an Loxone weiterverrechnen würden – besonders den Aufwand durch defekte Bestands-Karten.

Wir erwarten von Loxone eine Stabilität des Systems über 5 Jahre, ohne bei gewöhnlichem Betrieb im Einfamilienhaus regelmäßig SD-Karten tauschen zu müssen. Es muss möglich sein, dass der Kunde die SD-Karte selbstständig tauschen kann, ohne den Verteilerschrank öffnen zu müssen – das ist nur durch einen Kartenslot an der sichtbaren Oberseite des Geräts oder durch passende SD-Karten-Adapter möglich. Dies muss eine Standard-Lösung sein, um Kunden und Installateur unnötigen Ärger durch dieses unausgereifte System zu ersparen.

4. Die IT-Sicherheit des Loxone-Systems ist durch diverse Maßnahmen der letzten beiden Jahre zwar auf dem Weg der Besserung. Wie man angesichts der massiven DDoS bzw. SYN-Attacken vor einigen Wochen gesehen hat, herrscht seitens Loxone aber noch großer Handlungsbedarf. Noch immer wird in Ihrer Dokumentation der Port 80 als Standardport für die Visualisierung hergenommen. Wie Sie selbst schon erkannt haben, ist dieser Port eine große Schwachstelle für Angriffe von außen. Darauf wird zwar halbherzig hingewiesen, am grundlegenden Ansatz, wie Loxone seine Geräte für externen Zugriff freigeben lässt, ändert das aber nichts.

Ein sicherer Zugriff über das Internet ist über eine einfache Portfreigabe nicht realisierbar. Das Gerät hängt „offen“ am Internet und ist für Flood- sowie BruteForce- Attacken höchst anfällig. Das wurde durch einige Maßnahmen Ihrerseits zwar leicht verbessert, ist allerdings noch lange nicht das Gelbe vom Ei. Sobald ich die Portweiterleitung auf einen anderen Port als 80 auswähle, ist die Einrichtung über Ihren DNS-Server nicht mehr zuverlässig möglich, manche Miniserver werden in der App dann nicht mehr gefunden.

Auch die Art, wie der Miniserver mit Attacken von Außen umgeht, ist höchst bedenklich. Denn wenn der Miniserver durch DDoS-Angriffe tatsächlich lahmgelegt werden kann – dazu zähle ich Neustarts im Sekundentakt! – ist die Sicherheitsfunktion des Geräts eher nicht erwähnenswert. Ziel muss es doch sein, dass die Firewall die Angriffe blockt, meinetwegen die Visualisierung auch mal neu startet. Aber dass das SPS-Programm – also wie Sie so schön sagen das Herz des Hauses dadurch aus dem Tritt gebracht werden kann, ist einfach armselig und nicht hinnehmbar.

Wir fordern von Loxone eine brauchbare, dem gesunden Menschenverstand und gängigen IT-Formen entsprechende Sicherheitspolitik. Dazu gehört ein stabiler Betrieb der Haustechnik selbst trotz Attacken von Außen sowie ein sicherer Zugang auf das System. Aus Sicherheitsgründen erfolgt dieser nicht per Portfreigabe sondern über eine VPN-Verbindung. Dadurch würde sich auch die Lücke für äußere Attacken schließen. Damit die VPN-Verbindung dem typischen Installateur-Klientel gerecht wird, sollte sie möglichst einfach einzurichten sein.
Sollte der Miniserver selbst derartige Sicherheitsmaßnahmen nicht stemmen können, wäre evtl. eine „Security Extension“ denkbar, also eine Art VPN-Router, über den die gesamte Netzwerkkommunikation des Miniserver läuft und der auch die VPN-Verbindung für die App bereitstellen kann. Dies vom Installateur oder vom Kunden stillschweigend zu erwarten, ist aus unserer Sicht nicht tragbar.

5. Die Dokumentation des Minisever alleine als eine Art Online-Wiki mit Videos und Beispiel-Dateien aufzuziehen, ist auf den ersten Blick ganz neckisch. Nach zwei Jahren Arbeit mit Loxone weiß ich, nützlich ist das nicht.
Ihre Online-Dokumentation ist vorsichtig ausgedrückt in einem sehr schwachen Zustand, ein Großteil der Beiträge über etablierte Bausteine ist noch von der alten App bzw. der Config 6, zum Teil sind neue Funktionen der Config 8 / 8.1 noch gar nicht nachgetragen. Die Pop-Up-Hilfe in der Config kann manchmal helfen, meist ist das aber noch nicht ausreichend.
Dass es keine Möglichkeit gibt, die Dokumentation als „starres Werk“ in PDF- oder Papierform zu erhalten, stellt uns häufiger vor größere Probleme, ebenso das Fehlen jeglicher Dokumentation, die wir dem Endkunden übergeben könnten. Dazu gehören Infos, wie die App bedient wird, welche Bausteine es gibt und wie man diese einstellt. Natürlich gehört das zu einer sauberen Einweisung in das System dazu, aber welcher Endkunde kann sich alles merken, was man ihm in einer halben Stunde Einführung per Druckbetankung an Informationen liefert?

Jede Dokumentation, die wir dem Kunden übergeben, ist deshalb handgefertigt und bei weiten nicht vollständig, was die Bedienung der grundlegendsten Funktionen angeht. Dass wir uns diese Daten, Bilder und Anleitungen aus den Fingern saugen müssen, ist sehr schwach. Ebensowenig hat der Endkunde die Möglichkeit, über die Bedienung des Miniserver Ihre Website zu befragen, die gesamte Dokumentation ist auf den Programmierer/Bastler ausgelegt, nicht auf den DAU-Endkunden.

Unsere Forderung von Loxone ist deshalb eine saubere, aktuelle Dokumentation des gesamten Systems – sowohl für den Programmierer als auch zur (bearbeiteten) Weitergabe an den Endkunden. Nur so kann man sicherstellen, dass der Kunde sich bei Fragen gut aufgehoben fühlt und mit dem Betrieb seines Smart Home zurecht kommt.

6. Loxone bietet mit dem Programmbaustein und PicoC die Möglichkeit, eigene Programme in Form von Structured Text zu entwerfen – das bietet uns die Möglichkeit, eigene Algorithmen für das Energiemanagement einzusetzen, in die wir bereits einige Arbeit gesteckt haben. Immer wieder hat sich PicoC da als sehr performant und flexibel gezeigt. Die Handhabung dieser Programmiersprache – die ja offensichtlich auch von einem anderen Entwickler einfach übernommen wurde, obwohl es ansonsten keine große Verbreitung findet – ist kurz gesagt enttäuschend. Zwar werden einige Funktionen in der Online-Dokumentation (vgl. 5.) kurz erläutert und in ein paar Beispielen untergebracht, aber es werden bei weitem nicht alle Funktionen erklärt, die PicoC unterstützt. Das muss man sich aus diversen C90-Seiten heraussuchen und überprüfen, ob die Funktion dann auch tatsächlich vorhanden ist.

Dadurch, dass Loxone für PicoC keinerlei Compiler oder Test-Funktionen geschweige denn eine grobe Syntax-Überprüfung in der Config liefert, müssen alle Funktionen erst auf dem Miniserver getestet werden. Ich weiß nicht, wie richtige IT-Programmierer das machen, aber mir unterlaufen da doch immer wieder Fehler – sei es logische als auch natürlich diverse Syntaxfehler. Um die alle ausbügeln zu können, muss ein Programm mit 100 Zeilen ca. 10-20 Mal im Miniserver laufen und den jeweiligen Fehler im Log ausgeben. Was das für den SD-Karten-Verschleiß unseres Testgerätes heißt, müssen Sie ja am besten wissen.
Welchen Arbeitsaufwand das für den Programmierer verursacht, daran wurde hier nicht gedacht…

Von einer brauchbaren freien Programmierung erwarte ich eine saubere Dokumentation der Programmiersprache inkl. aller Funktionen, die unterstützt werden. Zusätzlich muss es irgendwie möglich sein, den Code offline zu testen (andere Compiler kann ich aufgrund der Loxone-eigenen Befehle auch nicht verwenden). Entsprechende Funktionen müssen in der Config enthalten sein, wenn Loxone es mit PicoC irgendwie ernst meint. So wie es jetzt ist, ist das sehr halbherzig. Vor allem, wenn man dem Kunden dann gleich wieder unterstellt, dass die PicoC-Programmierung IMMER die Fehlerquelle darstellt, sofern PicoC verwendet wird.

7. Die Anwesenheitssimulation wurde schon mehrmals mit großem Brimborium angekündigt – einmal sogar als selbstlernend aufgrund des Userverhaltens. Das wurde mittlerweile wieder „dumb“ gemacht, indem die Anwesenheitssimulation wohl nur noch zufällig anhand der vorgegebenen Parameter arbeitet. Und dann werden damit nicht einmal alle Bausteine unterstützt – warum kann ich die Anwesenheitssimulation nur mit EIB-Dimmer einbinden, nicht aber EIB-Taster? Das ist doch genauso ein Lichtschalter? Um einem Kunden mit Loxone als KNX-Visu die Anwesenheitssimulation zu ermöglichen, muss man erneut perverse Konstrukte aufstellen, die wieder sehr undurchsichtig und fehleranfällig sind.

8. Die Möglichkeiten der Jalousiebausteine und der Schaltuhr sind leider stark begrenzt. Wenn ein Kunde eine automatische Rollo-Fahrt am Morgen und am Abend will, endet das je Raum in ca. 10 Bausteinen von Radio-Buttons über Schaltuhr und diversen virtuellen Eingängen. Denn der Kunde möchte ja auswählen können, ob das Ganze anhand Sonnenauf- und Untergang oder auf Basis einer Schaltuhr passieren soll.

Und wenn der Kunde jetzt den Rollo um 6 Uhr hoch, aber 1h nach Sonnenuntergang herunterfahren möchte? Ähnliches gilt auch für eine Außenlichtsteuerung…
Ich sehe nicht ein, warum ich dem Kunden wie bei KNX eine derart starre Programmierung erstellen muss, die er nicht ändern kann – dann kann ich gleich KNX verwenden.

In der Schaltuhr sollte man die Zeiten der Sonne und feste Schaltzeiten beliebig kombinieren können. Das wäre ein gewaltiger Funktionssprung für den Kunden! Bereits vor Monaten habe ich Ihrem Support einen Vorschlag zu einer intelligenteren Schaltuhr als Featurewunsch eingereicht. Das wurde zur Kenntnis genommen, aber die Funktion der Bausteine wurde bisher leider nicht erweitert. Die neue Logik-Funktion, die der Kunde in der App einstellen kann, finde ich da sehr bedenklich, warum kann man das nicht über die entsprechenden Bausteine einstellen? Das gleiche gilt für die Kalender-Funktion, der Kunde sollte doch in der Lage sein, einen Kalendereintrag zu erstellen, z.B. wann er in Urlaub fährt. Warum das bisher einfach unter den Tisch fällt, ist mir unverständlich.

Wie gesagt, sind die meisten dieser Punkte schon seit Längerem bekannt und wurden schon von einigen Loxone-Usern angemahnt. Vieles davon würde eine große Arbeitserleichterung bzw. eine massive Steigerung der Usability sowohl für User als auch für die Programmierer darstellen.
Würde man behaupten, Loxone würde keine neuen Funktionen entwickeln, wäre das absolut falsch. Viele Änderungen – auch einige in der Config 8.1 sind hervorragend und erleichtern die Arbeit bereits deutlich. Leider trifft das nicht auf die vielen seit Langem offenen Punkte zu, die häufig in halbfertigem Zustand verkümmern.

Heute per Mail an Loxone. Damit man nicht sagen kann, unsere (Firma) Probleme werden nicht eindeutig kommuniziert...

**nonem** · 28.11.2016, 07:39

Man wird sie vermutlich nicht von ihrer Linie abbringen, aber man kann zumindest aufzeigen dass es nicht nur eine Handvoll Spinner sind, die sich an dieser Änderung stören.

Error 404: Account Has Been Deleted

https://loxfeedback.uservoice.com/forums/270310-verbesserungsvorschl%C3%A4ge-f%C3%BCr-loxone/suggestions/17259260-minimaler-abfragezyklus-f%C3%BCr-modbus-tcp-von-0-1s-zu

Auch wenn ich mittlerweile selbst an der Sinnhaftigkeit dieses Instruments zweifele, ist es zumindest ein Versuch.