js-controller 2.0 ab sofort im Latest Repo
-
@nieIP sagte:
DG_SZ_F2_FDK:0.LOW_BAT
Das ist der Name.
@nieIP sagte in js-controller 2.0 ab sofort im Latest Repo:
hm-rpc.1.0007D5699E98AF.0.LOW_BAT
Möchtest Du dafür keinen Alias verwenden ? Das würde sich bei einem Austausch (Defekt) gut machen.
-
@paul53 sagte in js-controller 2.0 ab sofort im Latest Repo:
@nieIP sagte:
DG_SZ_F2_FDK:0.LOW_BAT
Das ist der Name.
@nieIP sagte in js-controller 2.0 ab sofort im Latest Repo:
hm-rpc.1.0007D5699E98AF.0.LOW_BAT
Möchtest Du dafür keinen Alias verwenden ? Das würde sich bei einem Austausch (Defekt) gut machen.
Mit js-controller 1.x hat die Verwendung des Namens nicht dazu geführt, dass ein falsches Batt Low Symbol angezeigt wurde.
Wenn ich den Namen verwenden könnte, würde ich kein Alias brauchen, da der Name beim Gerätetausch nicht verändert wird.BTW ich hatte den Namen in das Feld nicht eingetragen, sondern beim Erstellen der View mit der Maus aus der Datenpunktliste selektiert.
Heute war es eigentlich nur ein Versuch den Datenpunkt mal zu löschen und neu zuzuweisen und dabei ist mir der Unterschied aufgefallen. -
@nieIP sagte:
Wenn ich den Namen verwenden könnte, würde ich kein Alias brauchen
Mir ist nicht bewusst, dass in Vis jemals die Datenpunktzuweisung per Name erfolgen konnte. Der Name wird lediglich angezeigt.
-
@MathiasJ sagte in js-controller 2.0 ab sofort im Latest Repo:
Haha..... Bei der CCU gehen nur 3.....
deshalb die Frage, weil ich evtl ein paar machen will, die die Glasbruchmelder überwachen.....Ne, bei der CCU3 gehen mehr. Habe aktuell 4 im Einsatz.
-
@MathiasJ es gibt technisch kein echtes Limit. effektiv hängt es davon ab wie viele Netzwerk Verbindungen dein host (der Master) abkann. Das muss man dann irgendwann tweaken ... aber da wärst Du dann schon bei ein paar tausend hosts oder Adaptern ;-))
Und ab irgend einem Punkt wirst du redis als DB brauchen.
-
@nieIP mir wäre auch neu das das mal tat. Daher die Frage: hast du jemals das lowbat gesehn? ;-)) scheinbar - und das passt zur Erkenntnis von sissiwup: ungültige ids führen scheinbar dazu das es angezeigt wird.
-
@nieIP ps: auch mit Vis 1.2.2 noch?
-
Guten Abend
ab sofort ist die 2.0.39 im Latest Repo. Es sind noch ein paar Kleinere Fixes dazugekommen:
- (Apollon77) "upgrade name" for a controller will return an error to use "upgrade self"
- (Apollon77) "upgrade all" will no longer update controller too
- (Apollon77) add some more checks in adapter.js for existence of states/objects
- (Apollon77) enhance
iobroker setup customfor Redis sentinel usage - (Apollon77) make sure flot store works again also with objects with empty names
-
@apollon77
Dankeschön.
Das heißt für meine Zwecke reicht es allemal. -
@apollon77
Als du damals den 2.0 vorgestellt hattest, da hast du irgendwas erzahlt, dass der Controller sich merkt von wo aus ein Adapter installiert wurde und somit die Updates leichter sind.
Ist dies schon voll integriert, bzw ist jetzt auch ein automatisches update von Adaptern möglich, die ausschließlich auf github sind? -
@e-s Das ist voll drin, wobei ich jetzt nicht weiss was Du mit "automatische updates von Adaptern " meinst.
Wenn man mit der 2.0 einen Adapter vom GitHub installiert wird versucht den aktuellen Commit von GitHub zu ermitteln, der auch installiert wurde und dieser wird gespeichert. Das ganze passiert im "system.adapter.name" Objekt. Falls der Commit nicht ermittelt werden kann merkt sich das System mindestens das es ein GitHub install war.
Falls jetzt danach der Adapter auf einen anderen Host verschoben wird oder ein "minimal-Backup" (iobroker-data kopiert) wiederhergestellt wird, wird der Adapter von dieser gemerkten URL wieder installiert anstelle von npm. Damit restauriert er idealerweise exakt die gleiche GitHub-Version wie vorher da war (auch wenn es zwischenzeitlich schon weitere Änderungen auf GitHub gab) oder mindestens den aktuellen GitHub Stand.
Das ist um was es hierbei geht.
-
@apollon77 sagte in js-controller 2.0 ab sofort im Latest Repo:
@nieIP ps: auch mit Vis 1.2.2 noch?
Falls die Frage war "ob die Symbole bei falsch definiertem Datenpunkt auch in Vis 1.2.2 noch angezeigt wurden", dann Ja.
-
@apollon77 sagte in js-controller 2.0 ab sofort im Latest Repo:
@nieIP mir wäre auch neu das das mal tat. Daher die Frage: hast du jemals das lowbat gesehn? ;-)) scheinbar - und das passt zur Erkenntnis von sissiwup: ungültige ids führen scheinbar dazu das es angezeigt wird.
nein, ich bin nicht sicher, dass jemals Symbole angezeigt wurden. Der View wird selten verwendet und Batterie leer Meldungen kommen eher aus der CCU
Ich bin ja froh, dass ich den Fehler (bei mir) gefunden habe.
-
Update auf 2.0.39....
bisher 0 Problemo.
Das WLAN-Problem gehe ich später an..... stecke im Moment mit Arbeit fest
@apollon77
man sollte mal erwähnen, dass Du wieder einmal großartige Arbeit geleistet hast. -
Also ich habe eine Vermutung. Wenn man ind er 1.5 nicht existente States abgefragt hat dann kam ein {val:null} zurück und damit hat vis den val mit null initialisiert. In der 2.0 werden nicht existente States als null zurückgegeben und damit in vis nicht initialisiert und haben daher "undefined" als Wert. Von daher, ja das ist was anders
Jetzt hängt es dann von den Widgets ab wie Sie damit umgehen. Bei hqwidgets ist beispielsweise ein explizites "wenn undefined dann true" im Code und das sorgt genau für den Anzeigeeffekt.
Ich habe noch ein vis Issue dazu gemacht. Aber am Ende muss man jetzt überlegen ob vis angepasst werden sollte oder die Widgets ...
-
@apollon77 2.0.39 läuft hier ohne Auffälligkeiten..
Vielen Dank, habt euch sehr viel Arbeit gemacht und das merkt man, Top!!
-
Bekomme aktuell folgende Fehlermeldung bei updaten des js-controller:
../src/linux/DeviceINQ.cc:35:14: fatal error: bluetooth/bluetooth.h: No such fil e or directory #include <bluetooth/bluetooth.h> ^~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make: *** [Release/obj.target/BluetoothSerialPort/src/linux/DeviceINQ.o] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/npm/node_module s/node-gyp/lib/build.js:262:23) gyp ERR! stack at ChildProcess.emit (events.js:198:13) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_proces s.js:248:12) gyp ERR! System Linux 4.15.0-66-generic gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gy p/bin/node-gyp.js" "configure" "build" gyp ERR! cwd /opt/iobroker/node_modules/node-bluetooth gyp ERR! node -v v10.16.3 gyp ERR! node-gyp -v v3.8.0 gyp ERR! not ok Starting node restart.jsWeiß lieder nicht was das zu bedeuten hat.
Was jedoch gut ist, trotz der Fehler läuft alles ohne Probleme. -
@Leviathan09 sagte in js-controller 2.0 ab sofort im Latest Repo:
bluetooth/bluetooth.h
Das hattest Du dann vorher auch schon: https://stackoverflow.com/questions/23436909/where-is-the-bluetooth-bluetooth-h-located-in-linux
-
@apollon77
Ich habe bisher nie etwas mit Bluetooth gemacht, habe auch kein Dongle und derzeit auch nicht vor Bluetooth in Verbindung mit ioBroker zu nutzen.Bei den bisherigen updates der 2er Version kamen diese Fehler nicht.
Erst seit Version 2.0.35 glaube ich, da spuckte mir "upgrade self" am ende aus ich müsste das Fix-Skript ausführen.
Das habe ich dann gemacht.
Seit dem kommt dann beim updaten des js-controller das was ich gepostet habe. -
@apollon77
Mir ging es um einen Adapter den ich per github installiert hatte, fb-checkpresence. Dieser hatte ein Push auf Version 0.5, unter Adapter stand nur installiert 0.4.
Für mich stellte sich jetzt die Frage ob dieser Push hätte erkannt werden sollen und mir ein Update vorgeschlagen hätte sollen.
So wie ich dich verstehe, hätte es passieren sollen. Ist aber entweder weil ich den Adapter vor dem 2.0 installiert habe oder weil an der Erkennung was falsch ist, eben nicht geschehen.
Dann weiß ich erstmal Bescheid.
