Ich nehme an, es gibt hier noch keine Neuigkeiten?
Ich habe jetzt mal einen FGRM-222 verbaut. War direkt defekt, da man das Rollo damit nicht runterfahren konnte, weder per Schalter, noch per IPS. Hochfahren ging…
Naja, kurzerhand gegen einen anderes Shutter-Modul getauscht. Dieses war aus einer Nachlieferung (ebenfalls V2.2, allerdings Datum 09.10.2013) - hier lag zumindest die korrekte Anleitung bei. Unterstützte Klassen sind aber identisch zu den hier geposteten Shuttern.
Mal eine Anfängerfrage: Wie kann ich mir denn die hier geposteten Dumps anzeigen lassen? Bei Debug sieht das bei mir irgendwie anders aus?
@Furby284: In einem anderen Thread hast Du geschrieben:
Wie kann ich denn meiner Instanz diese Klassen zuordnen?
Wie kann ich denn meiner Instanz diese Klassen zuordnen?
Regulär gar nicht. Ich hatte manuell die „settings.json“ von IPS bearbeitet.
Für jedes Z-Wave Gerät gibt es da einen Eintrag, der u.a. einen Key „settings“ enthält.
Da steht base64 (php: base64_decode) codiert für die Shutter2 folgendes drin:
Wenn man nun das 2. „<Class9 Value=„37“/>“ in „<Class9 Value=„38“/>“ ändert, bekommt der Shutter eine „Intensity“ Variable in der die aktuelle Position steht und die Zielposition lässt sich wählen.
Ich denke aber nicht, dass das der richtige Weg ist das Problem zu lösen.
Außerdem überschreibt IPS das wieder sobald man in der Instanz einmal auf „Laden“ klickt.
@paresy: Könntest du das Vergeben der Klassen wieder zulassen? Oder spricht was dagegen? Und vielleicht sogar die manuelle Anpassung der übrigen Einstellungen?
Kann man über IPS irgendwie einen Trace erstellen, der in Form eines Sniffer-Logs anzeigt, welche verfügbaren Klassen beim Einrichten/Laden einer FGRM-222 Instanz mitgeteilt werden?
Ich würde das gerne mal mit dem Fibaro-Support aufnehmen. Paresy ist zwar anscheinend bereits mit denen in Kontakt, aber wenn da ein paar mehr Leute nachfragen, kommt da ggf. ein wenig mehr Druck rein…
Nunja, mit dem Dump konnte ich denen noch nicht dienen, aber mit der Fehlerbeschreibung auf Basis dessen, was hier im Forum gepostet wurde ich was ich selbst identifiziert habe, schon.
Ist sicherlich nicht von Nachteil, wenn da jetzt von verschiedenen Seiten Bewegung rein kommt.
…(sieht - wenig verwunderlich - bei mir genauso aus) dann fällt mir noch auf, daß
[ol]
[li]die 25 (Dec 37) sogar dreimal auftaucht[/li][li]die 91 (Dec 145) auch zweimal auftaucht[/li][/ol]
Hat das was zu bedeuten oder sind das andere „Steuerzeichen“?
Das ist leider für mich alles noch unbekanntes Terrain. Kann mir vielleicht nochmal jemand - ganz kurz - erläutern, was der gesamte Rest des Dumps nach Klick auf den „Laden“-Button zu bedeuten hat?
Edit: Was mit gerade noch auffällt: In der Update-Zeile steht ja auch was von 26 (=38 dezimal). Wenn ich wupperi’s info zum Dump richtig deute, dann meldet doch der FGRM-222 die Klasse 38… Oder sind das am Ende der Zeile nur irgendwelche Steuerzeichen…?
@wupperi, hast Du bereits Feedback vom Fibaro-Support bekommen?
Ich hatte meinen Dump noch nicht verschickt, da ich mir nicht sicher bin, ob auf Basis unseres Dumps die Klasse 26 (=38 Dez) nicht doch unterstützt wird.
Gibt es irgendwo eine Erläuterung zum Protokoll bzw. eine Zusammenfassung, was die einzelnen Statements im Dump konkret bedeuten?
Die 0x26 ist mit sicherheit eher Protokoloverhead. Zähle doch einfach mal die gemeldeten Klassen…dann siehst Du ab wo overhead kommt.
Fibaro untersucht noch, kein Feedback ausser, dass sie untersuchen.
Na prima… Einzige Lösung, dass die Dinger mit IPS (richtig) funktionieren ist dann also darauf zu hoffen, dass Fibaro den Fehler erkennt, beseitigt und die bereits verkauften Aktoren umtauscht. Passiert das nicht, dann sind Teile - abgesehen von stupiden Rauf- und Runterfahren (aber dafür langt auch eine €10,- Zeitschaltuhr aus dem Baumarkt) - für IPS also nahezu unbrauchbar.
Und warum? Weil die Dinger eine Funktion, die sie haben, die nach Aussagen anderen Forenteilnehmer auch einwandfrei funktioniert und die man auch (korrigiert mich, wenn ich falsch liege) ohne großen Aufwand in IPS nutzen könnte, dogmatisch ausschliesst, weil der Standard sagt, dass die Nodes ihre Klassen korrekt melden sollen?!?
Ich glaube, der Z-Wave Standard sieht auch nicht vor, dass ich meine Z-Wave Rollo Steuerung mit Homematic Fenstersensoren koppeln kann und die dann auch noch einen Plugwise-Wallplug für die Abzugshaube steuert…
In meiner (bisher noch sehr kurzen) IPS-Karriere habe ich insbesondere die Flexibilität von IPS zu schätzen gelernt - warum also hier wegen eines solchen Dogmas die Flexibilität einschränken?
Ich sehe das genauso wie negotiator:
IPS hat den Charme hoch flexibel zu sein, u.a. auch, um Fehler an anderen Stellen zu kompensieren.
So wie z.B. diesen hier.
Natürlich liegt dieser Fehler nicht bei IPS aber es wäre ein Leichtes ihn mit diesem mächtigen Tool zu beheben.
Damit wird doch einer der Haupt-Vorteile dieser Software beschnitten. Warum?
Bevor wir eine vernünftige Lösung dafür anbieten (und die ist, dass wir das Teil anhand seiner ID erkennen und die Klasse intern automatisch setzen) werden wir auf eine Reaktion von Fibaro warten, da solch eine Lösung nur der Notfall sein kann. Außerdem kann es immer noch ein Interpretationsfehler unsereseits sein und wir werden hier keine Tricks anwenden, solange der Sachverhalt nicht eindeutig geklärt ist. Hier heißt es abwarten und Tee trinken.
paresy
PS: Klassen manuell setzen haben wir bis zur 2.6 erlaubt gehabt und damit keine gute Erfahrungen gemacht. An dem Thema wird auch nicht gerüttelt. Das muss ich leider so eindeutig sagen.
Klingt aus meiner Sicht erstmal vernünftig. Sofern sich die Teile mittelfristig artgerecht einsetzen lassen, bin ich zufrieden. Ich hatte schon die Befürchtung, dass meine Investition für die Tonne war.
Aber trotzdem nochmal die Frage - und entschuldige, wenn sie naiv ist (bin noch Laie): Wo läge denn das Problem, wenn man die manuelle Zuordnung der Klassen nach expliziter Freischaltung (d.h. nicht per Default, wegen mir auch jeweils isoliert pro Node und nach mehrmaliger Bestätigung von Gefahrenhinweisen ) zulassen würde?
Hey, jetzt fühl Dich nicht gleich auf den Schlips getreten :rolleyes:
Unter einem Dogma versteht man eine feststehende Definition oder eine grundlegende, normative (Lehr-)Meinung, deren Wahrheitsanspruch als unumstößlich festgestellt wird [Quelle: wikipedia].
Mal salopp zusammengefasst: „Wir könnten das ja lösen, aber z-wave Geräte müssen per Standard ihre Klassen richtig reporten“ zusammen mit „ist eine prinzipielle Entscheidung“… da sehe ich keinen grundsätzlichen Dissenz zu obiger Definition.
Für mich ist aber auch der Begriff „Dogma“ erstmal nicht grundsätzlich negativ belegt, daher sorry, wenn Du das so aufgefasst hast.
Wie eben schon beschrieben bin ich nach paresys Aussage auch wieder „beruhigt“. Ich hatte nach den Äußerungen hier die Befürchtung, dass es in die Richtung „Fibaro hält nicht nicht an den Standard, also uns egal dass es nicht funktioniert“ geht.
Also, ich biete Dir hiermit die Friedenspfeife an :o
Ist in Ordnung. Du kannst davon ausgehen, dass ich auch eine Lösung will, Problem ist nur, sobald man feedback gibt (wie ich es getan habe) wirds gleich zerissen
Du kannst davon ausgehen, dass ich auch eine Lösung will, Problem ist nur, sobald man feedback gibt (wie ich es getan habe) wirds gleich zerissen 