Config 8.1.11.11 unbrauchbar mit Modbus TCP

[Prof.Mobilux]

Anstelle dass Loxone immer wieder versucht durch Einschränkungen der Schnittstellen "unliebsame" Extension-Konkurrenz auszuschalten, sollten sie lieber auf ihre Kunden hören und endlich mal eine I/O-Extension rausbringen. NIEMAND kauft für 20 Fensterkontakte einen Haufen Extensions, wo dann zig Ein-/Ausgaänge brach liegen.

Aber diese Ignoranz kennen wir ja bereits... Was die beiden "Chefs" nicht brauchen, braucht auch der Rest der Welt nicht. Und so beschneiden sie lieber "stillschweigend" immer mehr Schnittstellen anstelle ein konkurrenzfähiges Produkt auf den Markt zu bringen.

Bin gespannt wann die UDP- und HTTP-Eingänge kastriert werden.

[Christian_RX7]

UDP hatte schon einige kurzzeitige Kastrationen hinter sich, war in V5 und V6 nahezu unbrauchbar.

[LoxFFB]

Für die Fensterkontakte kannst in zukunft die Nano DI Tree verwenden ! ;-)

[Gast]

Hallo zusammen,

würde mich gerne für die Infos bedanken.
Ein Update wäre eine Katastrophe bei mir...

habe be auch ein Ticket aufgemacht.
Evtl - könnte man im Wiki eine "fette Negativ- Liste" schreiben
und diese möglichst plastisch und lesenswert gestallten?
So dass Neukunden die sich speziell informieren diese finden und Loxone evtl. Einlenkt?

glaube mit Argumentieren ist da nix

Grüsse
Chridtian

[NetMac]

Folgendes hat Loxone bei Facebook auf Christian's Beitrag geantwortet.

Zitat Loxone:
Hallo Christian,
Bezüglich der Änderung der Modbus Schnittstelle:
Das Haupteinsatzgebiet von Modbus ist die Regelungstechnik. Eine Vielzahl an Messumformern, Frequenzumrichtern, Stellgliedern und vielen weiteren Geräten sind mit einer Modbus Schnittstelle ausgestattet.
Da wir im Loxone Support viele Vorfälle mit Fehlkonfigurationen hatten, in denen eine zu geringe Einstellung bei diesem Parameter zu massiven Einbußen in der Performance des Miniservers geführt hat, wurde der minimale Wert hier erhöht.
Diese Änderung wurde durchgeführt, um jederzeit eine einwandfreie Kommunikation zwischen Miniserver und allen Extensions sicherzustellen.
Für die Ansteuerung einer Heizung oder auch das Auslesen eines Stromzählers kann dieser Wert problemlos auch noch weiter erhöht werden.
lg
Zitat Ende

[Prof.Mobilux]

Das war doch klar. Wartet ab: bei UDP und HTTP wird das gleiche folgen.

[hismastersvoice]

So... Jetzt bin ich richtig sauer.
Ich werde das nächste Woche wenn ich wieder zurück bin unseren Rechtsanwalt in der Firma prüfen lassen.
Für mich stellen solche nachträglichen Veränderungen einen Mangel dar, mal sehen was er dazu meint.

Was denkt sich Loxone eigentlich dabei, so einfach Produkteigenschaften nachträglich so zu verändern das das Produkt schlechter wird.
Das können sie gerne bei neuen Geräten machen, aber nicht bei bestehenden.
Wir dürfen uns das nicht gefallen lassen!

Folgendes haben Professionelle Anwender auf Loxones Beitrag geantwortet.

Zitat Anwender:
Hallo Loxone,
natürlich verstehen wir das viele Stellglieder innerhalb einer Parametrierungs- Software auch Risiken enthalten.
Das sich durch eine Fehlkonfiguration plakativ gesagt ein ganzes Haus lahmlegen lässt,
ist natürlich kein schöner Umstand.
Wir gehen nicht davon aus, dass massive Eingriffe in den Geschäftsbereich Eurer Partner vorsätzlich geschehen oder
aus Rentabilität geleitet werden.
Trotzdem würden wir uns wünschen das wir, die mit dem Gesicht zum Kunden stehen mehr Beachtung finden.
Änderungen - und das ist uns schon länger bekannt - können weitreichende Auswirkungen haben.
Würden solche Änderungen innerhalb eines umfangreichen End- Test getestet werden hätte man dies bemerken können.

Massive Rückgänge in Eurer Software- Qualität und in Eurem Service machen uns das Leben schwer.
Vielleicht ist die ein Verweis auf die Performance des Miniservers nicht der einzige Weg um Probleme zu lösen.

[crasythom]

Na toll! Das meinen die doch hoffentlich nicht ernst! Dann sollen sie halt eine Sicherheitsabfrage einbauen!


Gesendet von iPhone mit Tapatalk

[Squarry]

Passt ja wieder mal zu Loxone: überheblich, eingeschränkte Kommunikation und leises Eliminieren von Fremdprodukten. Die KNX-Probleme interessieren ja offenbar auch nicht. Ich hoffe COMEXIO bekommt mehr Fahrt und wird zur richtigen Konkurrenz für Loxone.

[Christian L.]

Zu deutsch wir beschneiden euch wo wir wollen, keine Schnittstelle oder Funktion die wir heute noch anbieten ist Sicher. Und informieren werden wir darüber nicht, denn wir schreiben in den Change Bericht nur positive Dinge.

[Gast]

Ich bin soooooooo froh das ich auf KNX gesetzt habe und Loxone im Ernstfall sehr leicht ersetzten kann.

[tyke]

Habe ich auch so gemacht und vor kurzem den Umstieg gewagt. Mir ging die Firmenpolitik von Loxone immer mehr auf den Keks und die Basteleien, die notwendig waren um Dinge zu machen, die andere Systeme standardmäßig unterstützen, wurden immer mehr. Das Haus funktioniert jetzt großteils nativ durch die Boardmittel, die KNX sowieso schon bietet. Zuvor war meine KNX Installation dumm und der MS hat alles übernommen. Für Spezialfunktionen (Visu, Sonos, Squeeze, Alarmanlage, RGBW Lichtsteuerung, 1-Wire usw...) verwende ich Edomi. Die Hardware dafür hat mich keine 50.- gekostet und das System wird täglich durch die Mitarbeit der Community (knx-user-forum.de) mächtiger. Was es da mittlerweile an Logikbausteinen gibt lässt wirklich keine Wünsche mehr offen und das System wirkt, obwohl GPL, was KNX angeht um Welten professioneller als Loxone. Einzig die Visu Erstellung ist im Moment noch mit viel Arbeit verbunden - das wird sich dank Community wahrscheinlich auch bald lösen. Sucht mal auf Youtube nach Edomi um euch ein Bild zu machen.

Edomi wollte ich mir auch schon lange mal genauer ansehen. Mir fehlte leider. Bisher die Zeit dazu. Auf welcher Hardware läuft Edomi denn bei dir. Vielleicht ist es ja eine gute Alternative das der Miniserver über kurz oder lang bei mir raus fliegt.

[tyke]

Ich hab auf ebay einen Fujitsu S900 Thin Client um 15.- gekauft, dazu noch eine 16GB mSATA SSD um 20.- von Amazon. Du kannst aber auch einen alten Laptop dazu verwenden, dann hast du die USV auch gleich gratis an Board, muss nur 64Bit Systeme unterstützen. Die Busanbindung mache ich über ein MDT IP Interface (ca. 170.-), das hatte ich aber sowieso schon, da der Miniserver mit der aktuellen ETS Version nicht mehr funktioniert.
Ich war übrigens überrascht, wie viel mit KNX alleine schon möglich ist. Automatische Beschattung (Sonnenstandsabhängig), unterschiedliche Lichtszenen bei Tag und Nacht, Treppenlichtautomaten, Zentralfunktionen usw... ist alles nativ ohne weitere Logik oder Server direkt mit KNX umsetzbar. D.h. wenn der Server ausfällt gehen halt die Schaltuhren nicht und Sonos geht nicht automatisch an, sondern es muss manuell geschaltet werden und die 1-Wire Sensoren zeichnen die Parameter meiner Heizung nicht auf...alles nicht tragisch.

[Robert L.]

wobei es technisch gesehen ja stimmt, man muss das einschränken (beliebig viel/schnell pollen von modbus(tcp) geht einfach nicht)
generell ist es ja ein "blödsinn" eingänge die schnell reagieren sollen zu pollen


die "übliche" vorgehenweise von loxone (erst mal machen, dann denken) ist ihnen hier aber (mal wieder) auf den Kopf gefallen

gerade bei modbus tcp wurde hier ja laufend herumexperimentiert..

(modbus tcp hat die ersten paar versionen ja überhaupt nicht richtig funktioniert..., soweit ich das noch weiß)

die aktuelle lösung (5 sekunden ) ist aber auch blödsinn..
besser wäre die Gesamtanzahl pro sekunde (pro modbus tcp gerät?) zu beschränken..


dann kann man entweder wenige werte schnell abfragen, oder viele werte langsam..

theoretisch führt die 5 sekunden einstellung ja immer noch dazu dass der miniserver überlastet (wenn man nur genug Werte abfragt.)
natürlich erst bei wesentlich höheren Anzahl an Geräten/Werten

[Dhaaal]

Mein Ticket dazu bei Loxone wurde auch einfach geschlossen ohne konkrete Antwort. Es hieß nur, dass erst einmal in der Entwicklung nachgefragt werden muss.

[Pio435]

Florian - Loxone

Falls Du noch mitliest, jetzt wäre wieder einmal ein konkretes Statement seitens Loxone willkommen. Kann kaum glauben, dass man dieses Problem einfach mit einem Statement in Facebook stehen lässt.

Dachte bis heute, dass zumindest den Loxone-Partnern auf Aufgehöhte begegnet wird und Loxone einfach keine Bastler mehr will. Solche Einschnitte haben aber ein weitaus grössere Tragweite, vor allem für jene, welche Loxone-Systeme vertreiben. Ich pflichte hismastersvoice bei, dass dieser Einschnitt juristisch überprüft werden sollte, um festzustellen, ob hier ein nachträglicher Produktemangel zur Debatte steht. Schliesslich können in solchen Fällen erhebliche Mehrkosten auf Partner zukommen, wenn eine solche Spezifikation auschlaggebend für die Installation war.

Einmal mehr (nach KNX, 1-Wire, ENocean) ein absolutes NoGo und lässt leider befürchten, dass früher oder später Schnittstellen wie http, udp auch bis zur Unbrauchbarkeit beschnitten werden.

[crasythom]

Meines auch. Auf telefonische Rückfrage habe ich exakt den gleichen Textbaustein aus Facebook bekommen. Ich habe nochmal hingeschrieben.


Gesendet von iPhone mit Tapatalk

[a.stecher]

Ich habe auch hingeschrieben, und mich beschwert. Wie weiter oben schon gesagt, sollten das möglichst viele von uns tun, um hier Loxone auch einen echten Bedarf aufzuzeigen.

------- edit ------ hier die Antwort ------

• Hier meine Supportanfrage:

Hallo Loxone,
mit neuester Version wurde der Modbus-Abfragezyklus von 0.1 auf 5.0 Sekunden erhöht.
Das ist immerhin das 50-fache!
[...]
Loxone habe ich als ein nach-allen-Seiten-offenes System kennengelernt.
Diese Umstellung mit neuestem Update lässt Zweifel aufkommen. Wer weiß, ob Modbus in einem Monat überhaupt noch unterstützt wird. Und wie sieht es mit KNX oder anderen Schnittstellen aus...?

Ich verstehe, dass der Miniserver durch zu kurze Abfragezyklen belastet wird.
Dies kann ich allerdings auch problemlos mittels "falschem Verwenden" der Statistikfunktion erfolgen.

Daher stelle ich hiermit einen Change-Request:
- die Einstellung des Abfragezyklus soll dem Programmierer überlassen sein und auch zukünftig wieder minimal 0.1 s betragen
- bei Werten kleiner 5.0 einen Warnhinweis in der Loxone-Config einblenden

• und hier die Antwort:

Das Haupteinsatzgebiet von Modbus ist die Regelungstechnik. Eine Vielzahl an Messumformern, Frequenzumrichtern, Stellgliedern und vielen weiteren Geräten sind mit einer Modbus Schnittstelle ausgestattet. Da wir im Loxone Support viele Vorfälle mit Fehlkonfigurationen hatten, in denen eine zu geringe Einstellung bei diesem Parameter zu massiven Einbußen in der Performance des Miniservers geführt hat, wurde der minimale Wert hier erhöht.
Diese Änderung wurde durchgeführt, um jederzeit eine einwandfreie Kommunikation zwischen Miniserver und allen Extensions sicherzustellen.
Für die Ansteuerung einer Heizung oder auch das Auslesen eines Stromzählers kann dieser Wert problemlos auch noch weiter erhöht werden.
Nichts desto trotz werde ich Ihren Change-Request intern weitergeben.

• Fazit:

Man gibt es zumindest intern weiter ..... ich denke, wenn wir genug Loxone-Partner oder -User sind, die das Problem melden, wird des hoffentlich Beachtung finden....

[tyke]

Klingt fast so, wie die Begründung weshalb die 1-Wire Schnittstelle kastriert wurde: ...1-Wire ist hauptsächlich zum Messen von Temperaturen gedacht...

Im Klartext heißt das: Wir wollen verhindern, dass günstige 1-Wire und Modbus I/O Module verwendet werden, da wir dadurch Gewinneinbußen haben und Support für Produkte leisten müssen, die wir nicht verkauft haben.

[Christian L.]

Hier die Antwort von Loxone auf die weitere Anfrage:


Der Parameter kann nicht auf unter 5 Sekunden gestellt werden. Für die meisten Anwendungen ist das ausreichend, ansonsten muss man sich eventuell mit einer kleinen Zusatzlogik abhelfen.

[Dhaaal]

Verstehe ich nicht ganz, wie will ich mit einer Zusatzlogik das Abfrageintervall <5s bringen? Aber wie es aussieht schaltet Loxone auf stur.

[hismastersvoice]

Die zusätzliche Logik, soll wohl die fehlenden Werte interpretieren,
doch so intelligent ist keine Logik im MiniServer.

[Christian Fenzl]

Die zusätzliche Logik kann ich euch sagen:
Modbusserver 1: Wartezeit nach Start 5 Sekunden
Modbusserver 2: Wartezeit nach Start 6 Sekunden
Modbusserver 3: Wartezeit nach Start 7 Sekunden
Modbusserver 4: Wartezeit nach Start 8 Sekunden
Modbusserver 5: Wartezeit nach Start 9 Sekunden

[crasythom]

Hilft für RTU aber nicht


Gesendet von iPhone mit Tapatalk