UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[rewenode]

@mickym sagte in Zugriff auf iobroker via soket.io:

habe ich schon mal eine Minierfolg mit der ersten Node - auch wenn noch nicht alle Optionen implementiert sind

Na das nenne ich mal Biss haben! Gut gemacht.
Melde dich, wenn du mal 'nen Betatester brauchst.
Womit entwickelst du? Ich habe mir seinerzeit einen NR-Entwicklungscontainer gebastelt, mit dem ich dann sowohl unter VScode als auch mit den Chrome-Devtools debuggen konnte.
Mittlerweile sollte das ja ganz easy mit DEVContainer in VSCode gehen. Das bin ich grad am testen.

[mickym]

@rewenode Ich entwickle alles wie zur Steinzeit - keine Entwicklerumgebung. Ich habe zwar Visual Studio auf meinem Rechner, aber hab das nur mal gebraucht um ein VB Programm zu schreiben. Aber das ist auch egal, weil ich nicht vorhabe, dass jetzt dauernd zu machen.

Ja die Node funktioniert so weit - aber ich glaub ich muss das alles nochmal irgendwie umbauen - da ich den Ablauf intern noch nicht so ganz verstanden habe.

In Deiner Function Node kann ich alle Funktionen nacheinander absetzen und die funktionieren auch. In meiner Node geht immer nur eine Funktion, dann springt die Steuerung nicht mehr zurück bzw. die Variablen sind nicht mehr initialisiert. Eventuell muss ich mit new ein neues Objekt erzeugen und wie Deine Funktion quasi von außen ansteuern. Also bin zwar froh soweit gekommen zu sein und mal eine Node mit den Steuerelementen erzeugen zu können.

Ich dachte mir ganz einfach - die In-Node ist einfach eine Subscription auf die patterns. Nun wollte ich nur noch die "sende Nachrichten zum Start" Funktion implementieren und dachte mir OK, dann machst einfach erst mal getStates und anschließend die Subscriptions aber das funktioniert nicht.

Ich habe auch die Idee soweit umgesetzt - dass man diese Nodes mit einem Array füttert.

Auch die Ausgabe der Objekte als Payload ist im Prinzip bereits alles implementiert.

Beides alleine funktioniert bestens - aber hintereinander eben nicht.
Also evtl. nochmal alles umschmeissen.

Wenn ich gar nicht weiterkomme, dann werde ich diesen Stand wohl mal lassen und gehts halt nur mit einem getState, der zu Beginn und dann getriggert ausgibt - ich will irgendwelches asynchrones Gedöns mal außen vor lassen, mir raucht da eh schon der Kopf.
Wahrscheinlich mache ich das erst mal so, weil das einfacher für mich jetzt ist.. Dann hängt man zur Not auch mal 2 Nodes als Input an seinen Flow.

Was mir schon zu Beginn aufgefallen ist, dass ich die subscriptions und/oder getStates innerhalb der Funktion aufrufen muss, die den aktuellen connect Status liefert. Ansonsten wartet man bis in alle Ewigkeit und es passiert nichts.

Oje - vergiss erst mal alles. Die Idee war das jeder Node über einen eigenen Kontext eine Verbindung aufbaut und somit die subscriptions sich nicht ins Gehege kommen. Aber ich zumindest so kann ich gar keine Verbindungen doppelt aufbauen - da zerschießt es bereits das ganze Node Red Eventuell muss man das dann doch so machen, das man eine eigene Verbindungsnode braucht - aber dann kann ich mir das ganze auch sparen, da also socket.io gibst es schon listener und emit Nodes. Das wird alles kompliziert. Wobei prinzipiell müsste es gehen. Ich kann mit Deiner function Node und meiner eigenen Node - gleichzeitig eine Verbindung aufmachen und sehe auch 2 Verbindungen in der Instanz. Vielleicht muss man die servConn Objekte in einer eigenen Instanz im node-Context betreiben. Es ist in jedem Fall noch eine ganze Menge im Argen - weiß nicht, ob ich mir das zutraue.

[rewenode]

@mickym sagte in Zugriff auf iobroker via soket.io:

Was mir schon zu Beginn aufgefallen ist, dass ich die subscriptions und/oder getStates innerhalb der Funktion aufrufen muss, die den aktuellen connect Status liefert. Ansonsten wartet man bis in alle Ewigkeit und es passiert nichts.

Also, ich weis natürlich nicht, wie du dein node konkret implementiert hast. Ich hatte damals 2 Ansätze:

1. Ein Node pro Funktion mit einer Verbindung pro Flow (das kann man ja über servConn.init() machen. Dabei nimmst du nicht die node.id sondern irgend was flow-globales. An die Flow.id kommt man (glaube ich) innerhalb einer node nicht(oder nicht so einfach) ran.
   Die Variante ist relativ einfach, weil in der node-configuration halt nur dass Pattern-Array hinterlegt werden muss. Die Funktion steht ja bereits fest und die Weiterbearbeitung ist auch einfacher. Ob/wie das mit mehrfach Connect klappt kannst du ja mit meinem function-node Gedöns testen.

2. Universelles node mit allen Funktionen/Patterns
   Dabei muss in der node Konfiguration entweder:
   a) die Funktion und Pattern eingestellt werden können. Was dann allerdings auch nichts Anderes als Variante 1. ist, nur dass immer das gleiche node verwendet werden kann. Macht es übersichtlicher aber in der node Erstellung erst mal komplizierter. Evtl. kann man ja mit 1. anfangen z.B. ein subscribe-node und ein get-node. Und wenn beide funktionieren, versucht man die zu verallgemeinern und ein node draus zu machen. Und wenn das Prinzip klar ist, sollte der Rest kein Problem mehr sein.
   b) der node soll alle Funktionen gleichzeitig abbilden können wie in dem function-node Beispiel. Dabei muss in der node-Konfiguration jeweils Funktion und Pattern-Array als Bock eingegeben werden können. Also ein Array mit Spalte1=function, Spalte2=arrayOfPattern

Mir würde 2b natürlich am besten gefallen, aber beginnen würde ich mit 1.

[rewenode]

@mickym sagte in Zugriff auf iobroker via soket.io:

Aber ich zumindest so kann ich gar keine Verbindungen doppelt aufbauen

Habs grad getestet. Stimmt so kann ich auch keine mehrfachen Verbindungen aufbauen. Keine Ahnung warum. Bei meinen ersten Versuchen ging das. Vlt. finde ich das raus, wenn ich wieder debuggen kann;-)

[mickym]

@rewenode Ja ich glaube da muss man erst mal mehr verstehen, als ich es im Moment tue. Wie gesagt es geht parallel - aber mit 2 völlig unterschiedlichen Instanzen, sonst könnte ich ja nicht in einem Flow - mit Deiner function Node eine Verbindung aufbauen.

Aber ich kann halt nicht mit 2 meiner Nodes eine Verbindung aufbauen.

Ansonsten würde ich es vom Design her bei mir erst mal so lassen. Das funktioniert so wie bei der mqtt-Node in dem man unter Server für jede Node eine eigene Konfiguration hinterlegen kann. Das Problem ist dann eher, wie ich dies javaskript technisch umsetze. Mein erster Versuch es mit Klassen zu versuchen, da bin ich daran gescheitert, wie ich damit ordentlich kommuniziere.

Na egal - ich muss das erst mal sacken lassen - im Prinzip hab ich ja schon einiges gelernt.

[mickym]

Im Prinzip muss jeder Node seine eigene Verbindung aufbauen und das müssen unterschiedliche Instanzen sein, sonst kommen sich ja die unterschiedlichen subscriptions ins Gehege. Anderenfalls müsste man so was wie eine Pipe aufbauen, in der man quasi eigene Kommunikationskanäle in einem gemeinsamen servConn Objekt abhandelt. Aber wie gesagt, dass übersteigt momentan alles etwas meine Vorstellungskraft.

Vielleicht ist das auch nicht so schwierig - man müsste mit einem gemeinsamen servConn Objekt nur die Callback Funktion so anpassen, dass sie die Kommunikation zu den verschiedenen Nodes regelt. Aber das führt jetzt hier wahrscheinlich zu weit. Dann wäre es auch nur 1 Verbindung nötig. ;). Das servConn Objekt würde dann nur noch von dem Serverkonfigurations Node gehandelt.

Die Verbindung könnte dann einfach auf- und abgebaut werden, je nachdem wieviele nodes das Server Objekt nutzen. Klickt man auf die Zahl, dann bekommt das Server Objekt bzw. der Konfigurationsnode ja mit welche Nodes mit ihm verbunden sind und über die node.id müsste man dann solche Kommunikationskanäle steuern.

Ich merke es beginnen sich in meinem Kopf schon wieder Ideen zu formen, die dem NR-Konzept wahrscheinlich wesentlich mehr entsprechen. Ist halt mit mehr Arbeit verbunden und man fängt quasi wieder ein bisschen von vorne an.

Die Kommunikation mit der Serverkonfigurationsnode wird letztlich über den Befehl hergestellt,

wobei die Instanz des Serverkonfigurationsnodes ja manuell ausgewählt wird. Nur im entsprechenden HTML File ist dann die Referenz welche Node als Konfigurationstyp hinterlegt ist und somit welche Eigenschaften diese mitbringt.

Na vielleicht finde ich ja was unter der getNode Funktion.

[mickym]

@rewenode sagte in Zugriff auf iobroker via soket.io:

@mickym sagte in Zugriff auf iobroker via soket.io:

Oder liegt das an Deinem Browser (Safari - denke ich mal )

Also, da scheint etwas anderes bei dir im Argen zu sein.

Gerade getestet mit Safari und Chrome.

Alias-Objekt, das originale Object und Alle Objekte mit 2 Wildcards bringen alle das gleiche Ergebnis.

Ich möchte nochmal auf mein Problem mit meinem NodeRed-Adapter zurückkommen.
Dafür habe ich extra mein relatives leeres Projekt genommen, damit da nicht soviel dazwischenfunken kann.

Ich habe nun festgestellt, dass meine iobroker-IN nodes- auch den * als Wildcard unterstützen, aber nur wenn dieser am ENDE steht. Das was Du mit "instanz.0...STATE" funktioniert das geht bei mir nicht.

Ich habe hier mal einen Beweis in meinem Tasmota Ast:

Das scheint mir schon ein Bug in der In-Node zu sein. Bei der list Node kann ich das auch so machen.

@rewenode warum es bei Dir mit den HM Nodes geht - verstehe ich auch nicht. Aber inzwischen glaube ich nicht mehr generell an meine Umgebung, wenn es daran liegt, welche Datenpunkte nicht gehen. Kannst Du es ggf. nochmal mit einem anderen Ast - zum Beispiel mit Deinem Zigbee rotate versuchen . das klappt bei mir auch nur mit zigbee.*

@apollon77 Ich werde das gitHub issue noch vervollständigen, aber vielleicht kannst Du mir ja sagen, ob ihr offiziell nur den * am Ende einer iobroker-in Node supported? Bei einer List-Node geht es ja auch?

Ich habe nun alle Tests hier nochmal bildlich zusammengefasst und damit dokumentiert - an den Debug Nodes erkennt man ja ob was rauskommt oder nicht:

[rewenode]

@mickym sagte in Zugriff auf iobroker via soket.io:

Kannst Du es ggf. nochmal mit einem anderen Ast - zum Beispiel mit Deinem Zigbee rotate versuchen . das klappt bei mir auch nur mit zigbee.*

Das geht bei mir.

Ich glaube, ich kann da akut auch nicht weiter helfen, weil ich deinen Fall bei mir nicht simulieren kann. Allein das kann viele Gründe haben.
NR V0.20.8 (also längst nicht mehr die aktuellste - kann ich auf die Schnelle nicht aktualisieren) läuft bei mir in einem ARCH-Linux Container, der Browser ist Safari oder auch Chrome. Beide auf einem Mac. Win habe ich leider nicht.
Ich kann dir nur sagen, wie ich vorgehen würde, aber ob das hilfreich ist, weis ich natürlich auch nicht. Also spätestens an diesem Punkt mache ich erst weiter, wenn ich eine lauffähige Debug-Umgebung habe. Ich habs nicht so mit der Glaskugel;-) Irgendwann kommt der Punkt, da will ich sehen, was an den relevanten Stellen eigentlich wirklich anliegt.
Aber nicht falsch verstehen, mit Geduld kannst du das bestimmt auch anders finden, da sind die Arbeitsweisen halt verschieden.
Wenn ich trotzdem irgendwie helfen kann, gerne.

[mickym]

@rewenode Passt schon du hast ja schon mehr getan als ich zu wagen gehofft habe und hilft mir auch schon für einen WOrkaround weiter. Immerhon kann ich weiter oben im Baum nun ansetzen und bekomme die getriggerten Werte, die ich halt dann später ausfiltern kann. Vorher war ich ja der Meinung, dass es prinzipiell nicht geht. - ich hoffe dass die Entwickler da auch helfen können .

[rewenode]

@rewenode sagte in Zugriff auf iobroker via soket.io:

NR V0.20.8

Grad noch mal mit ner frischen NR V1.2.9 getestet. Das geht auch. Also, die NR Version läßt sich wohl ausschließen.

[mickym]

@rewenode

@apollon77 hat mir nun eine neue Version des Adapters zur Verfügung gestellt. Nun funktionieren die Wildcards in meinen "in Nodes" wie bei Dir. - Weiß nicht, was Du für eine Version hattest, als das ging. - Egal dieses Thema liegt nun bei den Akten. Das gesamte socket.io liegt deswegen wieder etwas auf Eis. - aber wenn ich Lust habe, dann nehme ich mir es nochmal vor - man lernt ja auch einiges dabei.