NEWS
Zugriff auf iobroker via soket.io
-
@rewenode OK damit finde ich vielleicht raus, was die Ursache ist. Wenn es aber ein Bug in der Node ist, werde ich das sicherlich nicht selbst beheben können, das muss dann sowieso der Adapterentwickler machen. Zudem es wahrscheinlich schwerer ist den Code zu verstehen, als wenn ich sowas selber mache. Ich bin auch noch nicht der Javascript Entwickler, dass mir das alles so leicht fällt.
-
@mickym sagte in Zugriff auf iobroker via soket.io:
Wenn es aber ein Bug in der Node ist, werde ich das sicherlich nicht selbst beheben können, das muss dann sowieso der Adapterentwickler machen.
Ja, das stimmt schon. Aber was soll man als Entwickler machen, wenn es (scheinbar) überall geht, nur bei einem nicht und man das auch nicht nachvollziehen kann;-(
@mickym sagte in Zugriff auf iobroker via soket.io:
Ich bin auch noch nicht der Javascript Entwickler, dass mir das alles so leicht fällt.
Ich leider auch nicht, deshalb tue ich mich auch so schwer, mein Gefrickel weiterzugeben
-
@rewenode Du bist trotzdem schon weiter bei der Programmierung - jedenfalls hast Du mir toll geholfen und nun kann ich da weitermachen.
Ich habe das Ganze Problem ja mal hier angehängt - mach dann aber wahrscheinlich noch ein Neues Issue auf.
https://github.com/ioBroker/ioBroker.node-red/issues/30
Zumindest sieht man daran, dass es 2018 - ok ist super alt - auch nicht gegangen ist. Sonst hätte dieser @Osrx seine Lampen mit "lamp.*" auslesen können.
Ja, das stimmt schon. Aber was soll man als Entwickler machen, wenn es (scheinbar) überall geht, nur bei einem nicht und man das auch nicht nachvollziehen kann;-(
Also ich hatte auch mal einen Fehler im backit-up Adapter und da konnte mir der Entwickler super weiterhelfen und hat den Fehler auch im Code gefunden.Da kam dann auch raus, dass es daran lag, dass ich ein lokales Backup gemacht habe usw. ..
Jedenfalls hat man da was dann zum Debuggen eingebaut - dass man es im Log sieht. Ich wüsste ja nicht mal, wo ich im Code suchen müsste.
Ich habe es gerade nochmal auf einem fast jungfräulichen Projekt nochmals versucht und den node-red Adapter auf debug gestellt - aber da kommt auch nichts bzw. raus:
node-red.0 2021-02-03 20:16:43.755 debug (7110) system.adapter.admin.0: logging true node-red.0 2021-02-03 20:15:39.043 debug (7110) system.adapter.admin.0: logging false node-red.0 2021-02-03 20:09:17.106 debug (7110) system.adapter.admin.0: logging true node-red.0 2021-02-03 20:09:05.971 debug (7110) 3 Feb 20:09:05 - [info] Gestartete geänderte Nodes node-red.0 2021-02-03 20:09:05.970 debug (7110) 3 Feb 20:09:05 - [info] Modifizierte Nodes werden gestartet node-red.0 2021-02-03 20:09:05.967 debug (7110) 3 Feb 20:09:05 - [info] Geänderte Nodes gestoppt node-red.0 2021-02-03 20:09:05.967 debug (7110) 3 Feb 20:09:05 - [info] Modifizierte Nodes werden gestoppt
Die Shellies aktualisieren ihre Datenpunkte im Minutentakt.
Das Einzige was ich finde - wenn ich den Node-Red Adapter auf Debug stelle ist, dass er irgendwie nach Datenpunkten sucht, die es tatsächlich nicht bzw. nicht mehr gibt.
node-red.0 2021-02-03 20:19:24.404 debug (7110) State "logic.states.occupancy" does not exist in the ioBroker node-red.0 2021-02-03 20:19:24.283 debug (7110) State "logic.states.occupancy" does not exist in the ioBroker node-red.0 2021-02-03 20:19:24.214 debug (7110) State "logic.states.illuminance" does not exist in the ioBroker node-red.0 2021-02-03 20:19:24.191 debug (7110) State "logic.states.occupancy" does not exist in the ioBroker
Allerdings kann ich alle Nodes durch suchen - ich finde keine Node noch den String auch wenn ich die ganze flows.json durchsuche!
-
@apollon77 Ich habe nun ein issue aufgemacht, da bei @rewenode die wildcards ja zu funktionieren scheinen.
-
@rewenode Ansonsten bin ich ein Stück weiter und hab nun die wichtigsten Funktionen getestet/implementiert.
Danke nochmals.
Die Zugriffe aufs Dateisystem spare ich mir erst mal.
Der nächste Schritt ist nun eigene Nodes zu basteln.
-
@mickym sagte in Zugriff auf iobroker via soket.io:
Der nächste Schritt ist nun eigene Nodes zu basteln.
Sieht doch schon mal gut aus was du da machst!
Wäre toll, wenn du das durchziehst. Das wird dann die ultimative Schnittstelle NR-ioB. Auf schwachbrüstigen ioB Rechnern kann man dann auch komplett auf den NR-Adapter verzichten. Das kann recht nützlich sein.Nachtrag
Sieh dir unbedingt nochmal die conn.js genauer an. da habe ich wirklich nur die offensichtlichsten html-Referenzen behandelt. Da wimmelt es aber sicher noch von so reload() - Sachen.
Hab zwar irgendwo gelesen, dass man die conn.js bei eigenen Adaptern verwenden soll, aber wenn es sich nicht um Bowser-socket.io Geschichten handelt scheint mir das keine optimale Lösung zu sein. -
@rewenode Ich glaube Du überschätzt mich wahrscheinlich. Ich bin wirklich ein blutiger Anfänger und muss mir soviel noch erarbeiten - teilweise selbst Grundlagen von Javascript - da meine Programmierzeit schon lange zurückliegt. Aber ich probiers halt.
Im Moment muss ich mich erst mal anhand der Beispiele einlesen, wie man solche Nodes überhaupt macht und alles soweit zusammenhängt. An Deinem Code in der Funktion habe ich erst mal bissi was verändert, damit der Output etwas näher an den NodeRed Standard angelehnt wird.
Auch Dein Sammeln der Eingaben über Arrays finde ich von Dir pfiffig - aber ich muss da noch sehen, was dann zentral bleibt und was ggf. doch in den Node Context kommt.
Aber wie gesagt ich bin ja schon froh, dass ich die Funktionalität mit NodeRed und der conn.js getestet und soweit verstanden habe und nicht mehr verzweifelt vor einem "es geht nicht" und ich weiß nicht mehr weiter stehe.
Bis ich auf die nächsten Probleme stoße - aber wie gesagt - mich drängt ja nichts.
Und wenn Du meinst, dass die Arbeit in jedem Fall sinnvoll ist - kann ich das ja auch zum Verstehen weitermachen - da ich hoffe, dass mein Problem mit den Wildcards im NR-Adapter trotzdem behoben werden.
Wenn ich mal etwas weiter bin - vielleicht können wir ja auch gemeinsam daran weiterarbeiten. Wie gesagt, Du warst mir eine große Hilfe, dass ich nun weitermachen kann.
-
@rewenode Dank Deines tollen Codes - habe ich schon mal eine Minierfolg mit der ersten Node - auch wenn noch nicht alle Optionen implementiert sind.
-
@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. -
@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.
-
@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:
-
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. -
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.
-
-
@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;-)
-
@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.
-
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.
-
@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:
-
@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. -
@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 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.
-
@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.