siri test version

[justme1968]

anbei eine test version des siri moduls das den autostart von homebridge per CoProcess erlaubt. die gleiche methode die auch für alexa, gassistant und tradfri verwndet wird.

wichtig:
- da sich im gegensatz zur umstellung bei alexa hat sich der executable name nicht geändert.
  d.h.: das modul kann nicht feststellen das es eine 'alte' installation ist die nicht automatisch gestartet werden soll
- den alten autostart deaktivieren
- im gegensatz zu den anderen drei modulen wird (noch) kein config file erzeugt.
  das config file muss in .homebridge des fhem users liegen

ps: es werden auch die events des npmjs moduls ausgewertet um den prozess vor einem update zu stoppen und danach wieder zu starten.

edit 2019-03-11: zeigt code, link url und qr-code in der detail ansicht an.

[hoppel118]

  das config file muss in .homebridge des fhem users liegen

Hm... Ich habe mir gerade vor ein paar Wochen mehrere Homebridge-Instanzen nach folgender Anleitung gebaut:

https://forum.smartapfel.de/forum/thread/910-homebridge-instanzen-anlegen/?postID=17043#post17043

Ich habe momentan 3 Instanzen, eine für Homematic, eine für Hue und eine für Xiaomi. Demnach habe ich nun auch 3 config files unter:

• /var/homebridge-homematic/config.json
• /var/homebridge-hue/config.json
• /var/homebridge-xiaomi/config.json

Außerdem habe ich auch 3 systemd Services:

• /etc/systemd/system/homebridge-homematic.service
• /etc/systemd/system/homebridge-hue.service
• /etc/systemd/system/homebridge-xiaomi.service

Wird das dann noch funktionieren?

Viele Grüße Hoppel

[justme1968]

aktuell würde das modul nur eine homebridge instanz mit einem config file starten lassen. das wäre dann das fhem bezogene.

alle anderen würdest du wie bisher starten.

ich schaue mal ob man auch mehrere instanzen über ein oder mehrere siri devices laufen lassen kann.

hue würde ich im übrigen über fhem laufen lassen. nicht über das homebridge plugin. das sind dann weniger verbindung zur bridge und da fhem dann immer den aktuellen zustand kennt auch weniger verzögerungen.

das gilt im zweifel auch für alle anderen plugins bei denenes um gerate geht die sowieso in fhem vorhanden sind.

[hoppel118]

Andre, wir sind uns einig! Alles muss über fhem laufen!

Das ist bei mir auch der Fall. Jede Homebridge-Instanz hat

• einen eigenen Name,
• einen eigenen Username,
• einen eigenen Port,
• eine eigene PIN
• und einen eigenen Homebridge-Raum in FHEM.

Raum-Bezeichnungen:

• Homebridge-Homematic
• Homebridge-Hue
• Homebridge-Xiaomi

Manche Räume sind so schneller verfügbar als andere. Außerdem verzögert der Xiaomi WLAN Saugroboter nicht das restliche Equipment beim Starten der Home oder EVE App.

Wie man diese Instanzen genau einrichtet, wollte ich eigentlich auch nochmal im Wiki beschreiben...

Ich plane übrigens nicht Homebridge-Plugins zu verwenden. fhem soll die zentrale Steuerung behalten.

Die Default-Homebridge Instanz habe ich übrigens disabled, sie startet nicht mehr mit beim Rechner-Neustart. Den entsprechenden Raum ,,Homebridge" gibt es im meinem fhem nicht mehr.

Ich hatte übrigens gelesen, dass pro Homebridge-Instanz max. 50 Geräte möglich sind. An der Grenze bin ich nun quasi bald, was meine Entscheidung für mehrere Instanzen dann nochmal untermauert hat. Gilt das wenn man FHEM im Hintergrund nutzt nicht?

Siri gibt es bei mir nur ein Mal.

Ich hoffe, dass du das irgendwie hinbekommst. Wenn nicht, wäre das echt doof.

Viele Grüße Hoppel

[justme1968]

ok. jetzt habe ich es verstanden. jedenfalls das prinzip. aber noch nicht das warum

warum eigne user? was genau verzögert der roboter? der start sollte doch unabhängig von den devices sein.



ja. das limit von etwa 50 geräten pro bridge gibt es. wo genau ist aber nicht ganz sicher. 54 gehen manchmal noch.


ich denke ich werde im modul entweder vorsehen das es mehrere zeilen in homebridgeFHEM-conf geben kann und pro zeile eine homebridge gestartet wird. das hätte den nachteil das es nur einen gesamt status gibt oder ich erlaube mehrere siri devices. das hätte den nachteil das ich schauen muss welches device das default device ist das auch automatisch eine default config erzeugt.

mal sehen. so oder so: dauert noch etwas.

[hoppel118]

warum eigne user?

Ich rede von dem username in der config.json:

"name": "Homebridge-XXX",
"username": "CC:22:3D:E3:CE:33",
"port": 518XX,
"pin": "XXX-XX-XXX",

Ich dachte, dass mindestens username und port (evtl. auch name) eindeutig sein müssen.

was genau verzögert der roboter? der start sollte doch unabhängig von den devices sein.

Der Start ja. Aber ich habe neulich gelesen, als ich Bonjour-Erreichbarkeitsprobleme in meinem Netzwerk hatte, dass manche (WLAN-)Geräte, teilweise das Starten/Laden der Homebridge entschleunigen, weil sie gerade nicht erreichbar sind. Einzelne Geräte können die Erreichbarkeit aller Geräte verzögern, hatte ich zumindest gelesen.

Mittlerweile habe ich öfters mal in meiner Umgebung gesehen, dass die Devices der verschiedenen Homebridge-Instanzen nicht alle sofort beim Starten der Home- bzw. EVE-App da sind. Manchmal sehe ich nach dem Start der EVE App noch kurz das rote Ausrufezeichen, meistens beim Roborock, obwohl der seine eigene Instanz hat. Manchmal ist Hue am langsamsten. Homematic ist quasi immer sofort da.

ja. das limit von etwa 50 geräten pro bridge gibt es. wo genau ist aber nicht ganz sicher. 54 gehen manchmal noch.

50 erreicht man relativ schnell... Wie viele hast du denn?

mal sehen. so oder so: dauert noch etwas.

Bin gespannt für welchen Weg du dich entscheidest. Ich bin da schmerzbefreit, so lange es irgendwie funktioniert.

Wenn du soweit bist, gib Bescheid, ich teste dann.

Schönen Sonntag Abend noch

[Esjay]

Guten Morgen Andre,
hast du schon Pläne die Version einzuchecken?
Mir ist es gestern nach einem Update passiert, dass ich die Version nachladen musste.
Da ich es jetzt weiß, ist es nicht ganz so schlimm, aber scheinbar hat noch niemand Probleme mit der Version.

Grüße

[justme1968]

ja. die version wird noch eingecheckt.

wenn das mit mehreren instanzen eingebaut ist.


ansonsten habe ich noch ein feedback... d.h. ich weiss nicht ob es niemand benutzt oder ob es wirklich keine probleme gibt
da es nur 4 downloads gab aber über 600 benutzer von siri vermute ich ersteres...

[Loredo]

Hi André,


habe es auf einem Testsystem probiert und es scheint soweit zu laufen.


Was mir irgendwie noch fehlt ist, dass man homebridge nicht mehr manuell hochfahren muss, um den Pairingcode bzw. den QR Code zu sehen. Angenommen die config.json würde nun noch automatisch generiert werden und ich wollte dort nicht nachschauen, dann wäre es gut den Pairingcode in FHEM einsehen zu können (QR Code wäre natürlich Hammer, aber nicht mal so eben einzubauen wahrscheinlich).

[Esjay]

Hi André,


habe es auf einem Testsystem probiert und es scheint soweit zu laufen.


Was mir irgendwie noch fehlt ist, dass man homebridge nicht mehr manuell hochfahren muss, um den Pairingcode bzw. den QR Code zu sehen. Angenommen die config.json würde nun noch automatisch generiert werden und ich wollte dort nicht nachschauen, dann wäre es gut den Pairingcode in FHEM einsehen zu können (QR Code wäre natürlich Hammer, aber nicht mal so eben einzubauen wahrscheinlich).

Wird wenig helfen, aber wenn du ins Log File schaust, siehst du ebenfalls den Pairing Code. Dafür musst du also nicht extra starten.

Grüße

[Loredo]

Zum testen habe ich FHEM im Vordergrund laufen lassen. Wenn ich den FHEM Prozess dann mit CTRL+C hart beende, wird homebridge wohl auch unsanft beendet und kommt anschließend nicht mehr hoch:

Code Auswählen Erweitern



events.js:173
      throw er; // Unhandled 'error' event
      ^


Error: listen EADDRINUSE: address already in use :::51826
    at Server.setupListenHandle [as _listen2] (net.js:1256:14)
    at listenInCluster (net.js:1304:12)
    at Server.listen (net.js:1392:7)
    at EventedHTTPServer.listen (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/util/eventedhttp.js:60:19)
    at HAPServer.listen (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/HAPServer.js:158:20)
    at Bridge.Accessory.publish (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/Accessory.js:609:16)
    at Server._publish (/usr/local/lib/node_modules/homebridge/lib/server.js:128:16)
    at Server.<anonymous> (/usr/local/lib/node_modules/homebridge/lib/server.js:404:14)
    at /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/util/once.js:16:19
    at FHEMPlatform.<anonymous> (/usr/local/lib/node_modules/homebridge-fhem/index.js:1179:22)
Emitted 'error' event at:
    at emitErrorNT (net.js:1283:
    at processTicksAndRejections (internal/process/next_tick.js:76:17)



Daran kann das siri Modul wahrscheinlich im ersten Schritt nicht viel ändern, aber vielleicht kann das siri Modul da "aufräumen", so dass homebridge wieder starten würde? Hab gerade noch nicht herausfinden können, was man da genau aufräumen müsste.




Edit: ach, natürlich ist der alte Homebridge Prozess nicht beendet und läuft weiter. Hätte der als Kindsprozess nicht beendet werden müssen? Zur Not könnte siri.pm den Prozess ja killen und dann selbst neu starten... keine Ahnung aber, wie man dann unterscheiden würde, ob der Prozess tatsächlich von siri.pm verwaltet werden soll oder nicht.

[justme1968]

es gibt eine neue version im ersten beitrag die zeigt in der detail ansicht
- den pairing code
- eine setup url die man auf einem iOS device direkt anklicken kann
- den qr code den man scannen kann.

der qr code wird über das google charts api erzeugt und eingebettet. lokal erzeugen wäre nur mit zusatz paketen möglich und zieht auch noch das aufräumen nach sich wenn mehr als eine homebridge instanz möglich wird. ausserdem müsste fhemweb noch icons neu laden. und ich weiss nicht was noch...

theoretisch könnte man auch den qr code aus der homebridge-fhem ausgabe lesen, aber die unicode fonts im browser sehen komisch aus.

ich denke mit dem google aufruf kann man leben...


das starten und stoppen ist leider nicht ganz so einfach. da hatte ich für alexa auch eine weile gekämpft bis es sauber ging. bei homebridge habe ich das executable leider nicht unter kontrolle.

ich wollte schauen ob ein patch akzeptiert wird. alternativ würde ich einen homebridge-fhem wrapper ausliefern. das würde auch das problem des executable namens lösen.

dauert aber noch.

[Loredo]

Funzt Eins A, danke!


Kannst du für den QR Code Abruf die URL noch von "https://chart.apis.google.com/" auf "//chart.apis.google.com/" umändern? Dann läd der Browser es mit dem Protokoll, über das der Rest auch geladen wurde und es gibt keine Probleme mit HTTPS und HTTP Security Headern.


Ich vermute du kannst nicht feststellen, ob eine aktuelle HK Bindung besteht und den QR Code nur dann einblenden?

[justme1968]

die url ist geändert und die version ganz oben neu hochgeladen.

nein. nicht ohne änderungen an alexa-fhem und ich weiss noch nicht ob man aus dem plugin überhaupt an die info kommt. steht aber schon auf der liste

vielleicht mache ich das bild aber noch etwas kleiner. bei meinen tests hat es auch mit 100x100 noch gut funktioniert.

[Heinz]

Hallo,
funktioniert das auch wenn Homebridge auf einem anderen Raspberry wie FHEM läuft?

Gruß Heinz