@tomgr
Ich würde mich schon mal anstellen, habe die homebridge bis jetzt auf dem Pi1 laufen und mir jetzt den 3er gegönnt, um dann eventuell noch die IPS dort zu installieren.
Besten Dank schonmal im voraus
Thilo
Hallo zusammen,
es ist eine neue Version in testing online.
Neues Gerät: WindowCovering
Und es sollte nun möglich sein in jedem Modul eine eigene Variable zu schalten, ohne dies explizit anhaken zu müssen, der Haken ob eine eigene Variable geschaltet werden soll, kann also ignoriert werden, der wird bei der Stable Version auch entfernt.
Viel Spaß beim testen.
Grüße,
Kai
Hallo Leute,
mal eine philosophische Frage:
Kai hat sein Modul offenbar so programmiert, das bei den Dimmern ein Wert zwischen 0 und 100 gesetzt wird.
Die bei mir im Modul verwendeten Dimmer laufen derzeit aber mit 0 bis 255.
Ich möchte mich an die „IPS-Standards“ halten, daher mich dem anpassen. (wieder ein Thema für den PHP-Modul-Leitfaden!)
Daher: Ist 0 bis 100 der IPS-Standard? Am Ende ist aber wichtig, dass die verschiedenen Modul gut miteinander laufen…
Joachim
Bei HM ist es 0,0 bis 1,0.
Es gibt da wohl keinen Standard, weil es an der verwendeten Hardware liegt ?!
Michael
Ist nicht ganz so, Kai hat den Dimmwert einstellbar gemacht. Es gehen auch 0-1, in 0,01 Schritten.oder auch 0-255.
Die Werte lassen sich in dem Modul einbinden.
0-100 ist der Wert den Apple vorgibt…
Ich kann jetzt nur für LCN und zwave sprechen.
zwave braucht Werte von 0-100 in 1er Schritten.
LCN kann auch mit 0-100 umgehen, rechnet aber intern um (bei alten Modulen in 2er Schritten, bei neuen in 0,5er Schritten).
Das muss alles unter einen Hut.
0-100 % ist normal, und muss für bestimme Geräte daher umgesetzt werden.
Hallo,
ja, ich habe einstellbar gemacht.
Das funktioniert aber zur Zeit NUR, wenn Status und Brightness unterschiedliche Variablen sind.
Bei HM ist dies nicht der Fall. Da gibt es LEVEL, diese Variable wird für Status und Brightness genutzt, da zerbreche ich mir gerade den Kopf, wie ich das hinbekomme.
Grüße,
Kai
Ich habe es bei HM nie probiert wie es sich mit RequestAction verhält, ob da 0-100 akzeptiert werden.
Für den Status kannst du ja vielleicht das Profil nutzen?
GetValueFormated?
Michael
Hallo,
das Umrechnen ist kein Problem.
Aber das beide Werte die selbe Variable nutzen, da hapert es irgendwie.
Grüße,
Kai
Hallo zusammen,
Update im testing Branch online.
Lightbulb - Dimmer und Status mit der selben Variable sollte funktionieren.
Danke an DG0JG fürs testen mit HomeMatic! 
Grüße,
Kai
Hallo,
habe gerade mal aktualisiert und bin auf den Test branch.
Flugs mal Fensterkontakt und Rauchmelder angelegt. Beim abrufen des Status ist mir die Homebridge in die Jagdgründe gegangen. Ich habe das gestern und vorgestern schon ein paar mal beobachtet, war mir aber nicht sicher ob vielleicht meine Diskstation auf der die Homebridge in Docker läuft in den Ruhezustand gefahren ist. Das kann ich gerade eben ausschließen.
D. h. schalten von Switch / Bulb geht , Stati abfragen nicht (bzw. wie geschrieben eingeschränkt), da bin ich aber auch noch logs schuldig bin aber noch nicht dazu gekommen.
Hier mal die letzten Log Einträge aus der Homebridge:
37m[2/16/2017, 9:47:45 PM]e[39m e[36m[websocket]e[39m e[90mcallback {"name":"Rauch Schlafzimmer","characteristic":"SmokeDetected","value":0}e[39m
e[35;1mEventedHTTPServer e[0m[::ffff:192.168.6.3] HTTP request: /characteristics?id=30.9 e[35m+6se[0m
e[35;1mHAPServer e[0m[CC:22:3D:E3:CE:30] HAP Request: GET /characteristics?id=30.9 e[35m+1mse[0m
e[33;1mAccessory e[0m[Homebridge] Getting value for Characteristic "Current Position" e[33m+0mse[0m
e[37m[2/16/2017, 9:47:50 PM]e[39m e[36m[websocket]e[39m e[90msendData {"topic":"get","service":"Window","payload":{"name":"Fenster Bad","characteristic":"CurrentPosition"}}e[39m
undefined:1
{"topic": "callback", "payload": {"name": "Fenster Bad", "characteristic": "CurrentPosition", "value": }}
^
SyntaxError: Unexpected token } in JSON at position 103
at Object.parse (native)
at Websocket.onMessage (/usr/lib/node_modules/homebridge-websocket/lib/websocket.js:73:18)
at Websocket.message (/usr/lib/node_modules/homebridge-websocket/lib/websocket.js:53:12)
at emitTwo (events.js:106:13)
at WebSocket.emit (events.js:191:7)
at Receiver.ontext (/usr/lib/node_modules/homebridge-websocket/node_modules/ws/lib/WebSocket.js:816:10)
at /usr/lib/node_modules/homebridge-websocket/node_modules/ws/lib/Receiver.js:477:18
at Receiver.applyExtensions (/usr/lib/node_modules/homebridge-websocket/node_modules/ws/lib/Receiver.js:364:5)
at /usr/lib/node_modules/homebridge-websocket/node_modules/ws/lib/Receiver.js:466:14
at Receiver.flush (/usr/lib/node_modules/homebridge-websocket/node_modules/ws/lib/Receiver.js:340:3)
BG, Frank
Hallo Frank,
was für ein Gerät nutzt du?
HomeKit erwartet folgendes:
Position:
Characteristic.PositionState.DECREASING = 0;
Characteristic.PositionState.INCREASING = 1;
Characteristic.PositionState.STOPPED = 2;
CurrentPosition und TargetPosition einen wert von 0 - 100.
Ich habe noch keine Umrechnung eingebaut.
Grüße,
Kai
Moin,
habe eben schnell mal gecheckt, du hast recht, ich hatte beim WindowCovering ein Konfigurationsfehler (falsches Gerät bei Status reingeschummelt).
Was für einen Rauchmelder hast du denn als Hardware? Ich habe einen HM-Sec-SD-2 der mir
- Auslösung
- ERROR_ALARM_TEST
- ERROR_SMOKE_CHAMBER
- INSTALL_TEST
- LOWBAT
an Statusvariablen anbietet (mit Homeatic easy install angelegt). Was hast du denn für StatusTampered vorgesehen?
Komme erst am WE wieder zum testen, werde dann auch noch mal geziehlt Logs aufzeichnen.
BG, Frank
Hallo Frank,
die Variablen sind von HomeKit vorgegeben.
StautsTampered ist für den Status vorgesehen, wenn jemand das Gerät manipuliert, also von der Decke schraubt.
Grüße,
Kai
Hi Frank,
schau mal da:
HAP-NodeJS/HomeKitTypes.js at master · KhaosT/HAP-NodeJS · GitHub
Da stehen die Service drin, mit den Daten, die die Homebridge erwartet.
Hallo zusammen,
es wäre super, wenn nochmal ein paar Leute die aktuelle testing Version einspielen würden und mir Rückmeldungen geben, ob noch alles funktioniert.
Danke.
Grüße,
Kai
Hi Kai,
ich komme hier mit dem testen gar nicht nach, so schnell bist du 
Außerdem habe ich das Problem, das ich nicht (immer) weiß, mit welchen Variablen ich deine Module bestücken soll. Zum Beispiel der Fenstersensor (HomebridgeWindow), der hat im Homematic nur den State aber dein Modul erwartet noch „Target“ und „Current“…aber ich bemühe mich mit dem testen (neben der Arbeit) nachzukommen
Ich habe dann einfach alle drei Angaben auf die Statevariable verlinkt, keine gute Idee 
Homebridge stürzt ab. Habe das angelegte Gerät übrigens gelöscht bekommen und jetzt läuft mein alter Stand wieder.
Ich glaube auch, das es bei mir etwas sensibler ist, da ich ein AppleTV3 im Netzwerk habe, welcher ja erst die Änderungen über die Cloud mitbekommen muss, da er ja als eine Art Zentrale fungiert…
so nebenbei: Wenn ich eine Instanz (zb HomebridgeWindow) erstelle, aber auf Anzahl 0 gehe und dann übernehme, gibt es eine Fehlermeldung: undefined Variable: devices in … on line 67
Tolle Arbeit!
Gruß
Adam
Hallo Kai,
habe gestern auf „testing“ umgestellt. Stelle jetzt fest, dass der Homebridge-Server nicht mehr durchläuft:
(aktueller Auszug aus dem Error-Log)
Joachim
Nachtrag: Vermute das bei der Umrechnung der Dimm-Werte die dabei vielleicht entstehenden Float-Werte nicht akzeptiert werden?
Vielleicht ist der Name schlecht gewählt, das Modul ist für Fensterantriebe. Ich glaube du denkst gerade an den Sensor ob das Fenster auf oder zu ist, kann das sein?
Dadurch braucht das Schalten und Abfragen etwas länger als ohne Zentrale.
Danke, sowas habe ich noch nie getestet, wird daran liegen, weil devices ein Array ist und das existiert dann natürlich nicht.
Danke, aber teilweise treibt es mich zur Zeit auch zur Weißglut! 
Hast du die jetzt aktuelle testing Version?
Wie sieht die Konfiguration des Dimmers in meinem Modul aus?
Dann kann ich das evtl. mal nachstellen.
Grüße,
Kai
…auf die Testing-Version habe ich gestern Abend umgestellt. Konfiguriert habe ich die Dimmer mit dem Wert 255. Genaueres kann ich Dir sagen, wenn ich vor meinem IPS sitze…
Joachim