Hi.
neuere Versionen vom cifs-utils unterstützen smb1 nur noch, wenn dies explizit als Parameter in den Mount Optionen angegeben wird. Ansonsten kommt diese Fehlermeldung. Nur die neuste Firmwareversion für die aktuellen Fritzbox Versionen können auch smb2/3.

Hi,
der Node-Red-Adapter sichert die Datei bei Änderungen im Objekt node-red.[adapternummer].flows . Dies ist ein config-Node, den man auch über die Admin-Seite ändern kann, wenn der Adapter ausgeschaltet ist.
Bei jedem Start des Adapters wird der Inhalt wieder in die Flow und Credential-Dateien geschrieben.

Die einfachste Möglichkeit, die Datei von außen zu verändern ist, die Datei laufenden Adapter zu editieren und erst anschließend, nachdem die Datei in das Objekt geschrieben wurde, den Adapter neu zu starten.

Hallo MrMuppet,

im js-controller hat sich in den letzten Wochen was verändert. Seit dem werden von den Adaptern States, die von anderen Adaptern geändert wurden, nur noch dann ausgewertet, wenn diese ACK=false haben (auf der Admin-Seite rot dargestellt werden).

Nur wenn ACK=false ist, werden die Werte dann an das jeweilige Gerät geschickt.

Dies betrifft insbesondere den hm-rega-Adapter, der alle Variablen aus der Homematic alle 30 Sekunden abruft und überschreibt. Dies dürfte wohl auch für alle anderen Adapter gelten, die die Werte regelmäßig pollen.

Der Out-Node in node-red ist hier ein wenig missverständlich. Der Type hat die beiden Werte "value" und "command". In Wirklichkeit wird hier aber gesteuert, ob der Wert ACK=true (bei value) oder ACK=false (bei command) haben soll. Für alle States, die in einem Adapter eine Aktion auslösen sollen, muss der Type nun auf command stehen. Ansonsten passiert danach nichts.

"Block unless Value changes" gibt es nur für den in-Node. Dieser sorgt dafür, dass der Flow nicht bei allen Aktualisierungen des States aufgerufen wird sondern nur, wenn sich auch der Wert geändert hat. Der js-controller informiert normalerweise nicht nur bei Wert-Änderungen, sondern auch, wenn sich eines der Attribute (ACK-Flag, Datum der letzten Änderung usw.) geändert hat. Dies würde z.B. bei States des hm-rega Adapter dazu führen, dass der Flow alle 30 Sekunden gestartet wird, auch wenn sich der Wert nicht geändert hat.

Punkt 2 kann ich so nicht nachvollziehen.

Zu 3:

in ioBroker gibt es prinzipiell drei Möglichkeiten zur Automatisierung:

Szenen:

Erlaubt einfache Konfigurationsübergänge.

Javascript-Adapter:

Sehr gut in ioBroker integriert. Man kann alle Funktionen der Adapter nutzen. Jedoch nur wenig bis keine Tool-Unterstützung.

Für die meisten, die zuvor schon programmiert haben, wohl die auf den ersten Blick intuitivste Möglichkeit.

node-red:

Grafische Oberfläche und Dialoge suggerieren schnelle Erfolge. Der flussbasierte Ablauf mit dem Nachrichtenweiterschieben ist jedoch gerade für Skriptprogrammierer gewöhnungsbedürftig. Node-Red ist eigentlich ein eigenständiges Open Source-Projekt von IBM. Die Integration in IOBroker beschränkt sich zurzeit auf die drei Nodes. Auf Funktionen anderer ioBroker-Adapter kann aber über ein Javascript-Objekt zugegriffen werden.

Die eigentliche Stärke von Node-Red sind neben der Oberfläche mit integrierter Debug-Funktion die vielen fertigen Adapter, die unter http://flows.nodered.org/ aufgelistet sind. Falls man aber mal eine etwas komplexere Logik abbilden will, kommt man auch hier nicht um das Schreiben von Javascript herum.

Ob nun Javascript oder node-red ist zum einen Geschmacksache und hängt von den konkreten Anforderungen ab. Es ist zum Beispiel mit Node-Red erheblich einfacher, die gpio-Ports des Pi anzusprechen, periodisch Temperatursensoren auszulesen, Funktionen als Webservice oder über eine REST-Api bereitzustellen oder abzufragen usw. Vieles davon würde zwar auch mit dem Javascript-Adapter und/oder ioBroker-Adaptern funktionieren, aber der Zeitbedarf ist hier aus meiner Sicht höher, weil man sich dann erstmal in deren Logik oder den nativen node.js-Modulen einarbeiten muss.

Zu 4:

In und get-Nodes lesen die States aus dem js-controller aus. Dies erfolgt jedoch nicht bei jedem Aufruf des edit-Dialogs eines in- oder get-Node sondern nur einmal. Wenn der node-red-Adapter und somit auch node-red neu gestartet werden, sollten neue Werte auch angezeigt werden (wenn sie auf der ioBroker-Admin-Seite auch angezeigt werden).

Es gibt im Node keine Persistierung der Daten, somit kann die veraltete Liste nicht aus node-red kommen. Wäre aber auch möglich, dass diese Daten vom Browser aus dem Cache genommen werden.

Hallo agria4800,

schön, dass du dir den Adapter anschaust.

Nach der Installation sollten eigentlich die vier in der Abbildung dargestellten Widgets erscheinen.

Irgendwie scheint es aber mit der package-oi oder allgemein ein Problem zu geben, weswegen VIS bei der Installation die Widgets nicht neu einliest. Wenn jemand hier einen Tipp hat, wie man VIS im Rahmen der Installation zum Einlesen der Widgets bringen kann, wäre ich dankbar (restart vis steht drin).

Kannst du bitte in der Adapteransicht im Admin einen Upload des VIS-Adapters durchführen? (geht nur in der Expertenansicht).
Danach sollten sie dann hoffentlich angezeigt werden.

Hallo IoBroker Gemeinde,

ich hab mich seit einer längeren Auszeit mal wieder etwas ausführlicher mit meiner Visualisierung beschäftigt und dabei ein paar VIS Widgets mit Charts für einen speziellen Anwendungszweck erstellt:
Drei der Diagramme verwenden History-Werte, die auf den Save-Werten des Statisik-Adapters erstellt wurden und zusätzlichen den aktuellen Wert im Temp-Zweig, um die Jahres, Monats, Wochen. Tages oder Stundenwerte darzustellen. Hierbei wird für die Periode jeweils nur der letzte History-Wert verwendet, da nur dieser den korrekten Endwert enthält.
Das Chart für die Jahreswerte stellt die Werte von bis zu vier Datenreihen der letzten vier Jahre gegenüber. Das Chart für die Monatswerte stellt die Monate der letzten drei Jahre als 3D-Balkendiagramm dar.

Darüber hinaus gibt es noch drei Zeitreihendiagramme. Zwei davon mit Navigator-Diagramm. Das erste ist wieder für die Darstellung von aggregierten Werten vom Statistic Adapter gedacht, die anderen beiden stellen ganz normale Zeitreihen aus dem SQL-Adapter dar. Obwohl diese bei mir alle bisherigen Flot-Diagramme ersetzt haben, hab ich aber nicht den Anspruch, dass diese vollwertigen Ersatz für Flot oder eCharts sein sollen.

Die Charts werden mit highcharts und highstock dargestellt. Dies wird bei der Installation automatisch mit npm installiert und die js-Dateien kopiert. Hieraus ergibt sich, dass der Adapter nur für die nicht-kommerzielle Nutzung kostenlos ist. Ansonsten wird eine Lizenz für Highcharts benötigt.

Im Gegensatz zu Flot oder eCharts handelt es sich hierbei um eine Widget-only Lösung. Alles wird direkt in den Parametern der Widget eingestellt. Die Daten werden über das Connection-Objekt von VIS geladen (Firewall und Reverse-Proxy kompatibel). Auch in der selbst kompilierten Cordova-App funktionieren die Widgets bei mir.

Weitere Infos befinden sich in der Readme-Datei.

Warum Highcharts:
Ich hatte es eine ganze Weile mit Flot gelöst, aber irgendwie sahen die Diagramme immer nur "ganz nett" aus.
Zum einen bietet Highstock einen Navigator, der sehr gut für die Darstellung großer Datenmengen und das Rein-zoomen eignet. Die eigentlichen Daten werden dynamisch nachgeladen. Mit dem boost-Modul kommt Highcharts auch mit sehr großen Datenmengen klar. Ich hab die Produktions- und Zählerwerten mit 10 Sekunden Auflösung und möchte da bis auf die Einzelwerte reinzoomen können. Optik und Zusatzfunktionen wie Fullscreen und Export sind natürlich auch schön.

Einschränkungen:
Da meine Zeitreihen teilweise Werte alle 10 Sekunden haben, geht meine Maria-DB in die Knie, wenn die Navigator-Daten für mehr als 4 Monate mit den Standardfunktionen der History-Schnittstelle abgerufen werden. Deswegen verwendet ich für den Abruf spezielle SQL-Statements, die die Datenmenge bereits im DBMS deutlich reduzieren. Die SQL-Statements funktionieren aber nur mit MariaDB oder MySQL. Ich hab noch keinen Fallback implementiert, falls die Quelle eine andere ist.

Ich hatte bei den ersten Release-Versuchen etwas Probleme mit den gulp-Skript. Mit der Version 1.0.6 sollte die Installation nun aber über npm funktionieren. Eventuell muss danach noch einmal ein Upload für VIS durchgeführt werden, falls die Widgets nicht angeboten werden.

Bitte schreibt mir, ob die Installation und die Widgets soweit funktionieren.

mfg
Markus

Hi,
auf dem Screenshot im Hintergrund steht eine Fehlermeldung für iobroker.pro ...
Kann es sein, dass du die URL ganz unten unter mobile Verbindung eingetragen hast und/oder dort auch noch iobroker.pro aktiviert hast?

Lösche da unten mal alles, schalte pro aus und gebe nur oben unter WIFI Verbindung die Socket URL ein.
Direkt nach dem Einschalten der App sollten oben immer erstmal die drei Punkte für die Einstellungen erscheinen, wenn nicht sollte das Löschen der App-Daten in den Android-Einstellungen helfen.

Hallo Patrik,

ich hab leider kein loxone und kann den Fehler leider auch nur begrenzt nachvollziehen.
Auch kenne ich die Flows der Benutzer nicht.

Die Ausgabe im Issue verweist auf die Zeile 282 in der Node-Definition von ioBroker (ioBroker.js).
Diese gehört zum Out-Node (https://github.com/ioBroker/ioBroker.node-red/blob/master/nodes/ioBroker.js). Diese Stelle wird somit nur dann durchlaufen, wenn es einen Flow gibt, die einen ioBroker Out-Node enthält und dieser ein msg-Objekt bekommt. Die reine Installation des node-red-contrib-loxone sollte eigentlich hier nichts bewirken.

Zur betreffenden Code-Stelle:

node.status({fill: 'green', shape: 'dot', text: msg.payload.toString() });

Wenn ein Wert in den Key-Value-Store von ioBroker geschrieben wurde versucht der Node, den geschriebenen Inhalt als Text direkt am Node anzuzeigen. Da iobroker auch Zahlen oder Objekte als Input erlaubt, wird hier nach String konvertiert. Das Vorhandensein des Attributs payload im msg-Objekt wird jedoch nicht geprüft. Wahrscheinlich wurde ein komplett leeres Objekt oder etwas anderes als ein Objekt (z.B. Zahl, String) als msg übergeben. Deswegen schlägt der Zugriff auf msg.payload fehl und es kommt zu der Exception.

Soweit mein Versuch einer Interpretation.

@MrLee
Das Bauen ist nicht das Problem. Auch das Aufnehmen der neuen Adapter nicht.
Aber die neue Version muss mit dem richtigen Zertifikat signiert und anschließend auf dem Playstore hochgeladen werden. Das kann nur bluefox machen.
Auch das direkte Verteilen der APK ist leider nicht erlaubt.

Hi,
der Node-Red-Adapter sichert die Datei bei Änderungen im Objekt node-red.[adapternummer].flows . Dies ist ein config-Node, den man auch über die Admin-Seite ändern kann, wenn der Adapter ausgeschaltet ist.
Bei jedem Start des Adapters wird der Inhalt wieder in die Flow und Credential-Dateien geschrieben.

Die einfachste Möglichkeit, die Datei von außen zu verändern ist, die Datei laufenden Adapter zu editieren und erst anschließend, nachdem die Datei in das Objekt geschrieben wurde, den Adapter neu zu starten.

@Mario-Doell
Kannst du mal nachsehen, in welchem Verzeichnis node-red installiert wurde und wo @node-red?
Zu 1: Mit welchem User hast du das npm-Kommando aufgerufen? Wenn das zuvor mit user iobroker installiert wurde, muss das mit root erfolgen oder mit sudo vor dem npm.

@Mario-Doell
Wenn du die Fehlermeldung

module.js:550 throw err; ^ Error: Cannot find module '/opt/iobroker/node_modules/iobroker.node-red/node_modules/node-red/red.js' at Function.Module._resolveFilename (module.js:548:15)

hast, dann liegt es daran, dass du bereits nodered auf Version 0.20.x angehoben hast. Diese läuft mit dem alten node-red-Adapter nicht. Da die geforderte Version von Node-Red im Adapter-Package nur mit ~ angegeben wurde, wird bei Neuinstallation des Adapters die neuere Version von Node-Red nicht durch die 0.19.6 ersetzt.

Du hast jetzt mehrere Möglichkeiten, dies Problem zu lösen:

1. manueller Downgrade von Node-red über RPM:
   Beende den node-red-Adapter und damit auch node-red.
   Überprüfe, in welchem Verzeichnis Node-Red (nicht der iobroker.node-red) installiert wurde. Dies sollte
   /opt/iobroker/node_modules/node-red sein.
   Wenn dies der Fall ist, gehe in das Verzeichnis /opt/iobroker und gebe dort das folgende Kommando ein:

npm install node-red@0.19.6

Starte danach wieder den node-red-Adapter.

Sollte iobroker bei dir mit dem User iobroker statt root laufen (wird beim Starten eine Fehlermeldung im Log angezeigt), musst du ggf. auch noch den Besitzer des Verzeichnisses
/opt/iobroker/node_modules/node-red auf iobroker ändern.

2. Installation der Version aus meinem Pull-Request. Dieser ist aber bisher nur von mir geprüft.
   Dies kannst du direkt über die Admin-Seite machen, in dem du bei der Installation aus einener URL auf den Reiter Beliebig gehst und da folgende URL angibst:

https://github.com/nobodyMO/ioBroker.node-red.git

Sichere dir aber bitte vorher die flows.json und die flows-cred.json aus deinem Datenverzeichnis (/opt/iobroker/iobroker-data/node-red). Die 0.20.0 hatte einen schweren Bug, bei dem im Zusammenspiel mit dem Kopieren der Flows durch den Adapter mit jeder Veröffentlichung alle Objekte in der flows,json verdoppelt wurden. Dieser Fehler ist bei mir aber mit der 0.20.3 nicht mehr aufgetreten. Diese läuft bei mir nun seit 10 Tagen stabil.

3. Warten
   Der Pull-Request ist nun 8 Tage alt. Keine Ahnung, wann ob und wann die neue Version veröffentlicht wird.

Hi.
im Github Master ist ein Bug drin, weswegen die Nodes den Pfad zur Controller Lib nicht mehr finden. Deswegen werden beim Start von nodered die Nodes entfernt.
Den Fehler hab ich in meinem Pull-Request zur nodered 0.20.3 behoben. Die ist aber noch nicht in dem Master übernommen worden.
Die Version auf npm geht nicht?

Bitte auch nicht die Version des Nodered-Adapters in iobroker mit der Versionsnummer von Nodered selbst verwechseln.
Der Adapter hat die Version 1.7.2. Die durch diesen installierte Nodered-Version ist 0.19.x.
Die neueste Version von nodered ist 0.20.3. Diese ist definitiv noch nicht kompatibel mit der npm Version 1.7.2 des Nodered Adapters, da hier nodered in mehrere Module aufgesplittet wurde.

@viper2004
Hi,
das Problem ist nicht so wirklich neu und liegt an Chrome bzw. der Chrome Engine von Android, die für die Darstellung der Webinhalte in der App genutzt werden.
Google hat inline-Authentifizierungen in der Url schon vor einiger Zeit explizit abgekündigt, dann gab es viele Beschwerden und es ging wieder für ein paar Versionen bis es dann endgültig zurückgebaut wurde.

Ich nutze als Alternative die Authentifizierung über URL-Parameter, die bei mir ein Apache Web-Server als Reverse Proxy prüft und dann den Request an die Cams weiterschickt.
Solltest du die App nur im lokalen Netz nutzen wollen, sollte der Proxy-Adapter dein Problem lösen können.