NEWS
[Aufruf] deConz Adapter Testen 1.1.2
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Ich habe aber auch alles andere von dem raspi entfernt.
Den 3B+ habe ich auch, aber dann ist es ja fast so, wie ich es vermutet habe, dass der Raspi damit alleine gut ausgelastet ist. Dazu kommt dann eventuell noch die Eigenperformance der SD Karte und des Raspi selber (Stichwort: Montagsmodell )Dann ist das System für mich eher fragil als stabil.
Ich bin da eher der Freund von wenig Wartung an den Systemen. Das Gateway brauchte ich in den knapp 3 Jahren, wo ich es nutze nicht einmal neustarten oder anderweitig pflegen. Selbstverständlich kümmere ich mich auch dann, wenn es notwendig sein muss, aber die Gefahr der Frau dann telefonisch zu Hause zu erklären, wie sie den Raspi neu startet um Licht in der Küche anmachen zu können, ist mir dann tatsächlich zu hoch.Vielleicht schaue ich mir tatsächlich nochmal die Docker-Variante an. Damit war ich eigentlich auch zufrieden, als ioBroker darauf lief, jedoch gingen meine Festplatten nicht mehr schlafen und deshalb hab ich davon Abstand genommen.
Ein Test mit deConz kann nicht schaden, bevor ich jetzt blind nen NUC kaufe. Und ich kenne mich. Dann wird es mindestens ein i3, weil man könnte ja später noch dies.....und das....und schwupps 400 Schleifen weg.
Das ist dann noch schlimmer als kein Licht in der Küche zu haben, wenn ich daran denke, wie meine Frau dann darauf reagiert. Hehe... -
Bei mir läuft alles auf einem NUC seit 2017 mit deConz und ist wirklich super Stabil.
-
@Jey-Cee sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Bei mir läuft alles auf einem NUC seit 2017 mit deConz und ist wirklich super Stabil.
@Jey-Cee
Darf ich fragen was mit "alles" gemeint ist? Nur Conbee oder auch ioBroker inkl. sämtlicher Adapter und Visu?
Was ist das für ein NUC (Ausstattung) und welches OS?Nachtrag:
Ich habe überlegt, ob es Sinn ergibt, dass ich testhalber auch mal das Image von Dresden-Elektronik nutze?
Das dürfte doch auf die Nutzung von Conbee passend zurechtgeschnitten sein.
Deren Gateway für 150 Öcken kann doch auch nur ein PI im Gehäuse mit Conbee Modul sein, oder? -
ioBroker (inklusive aller Adapter), deConz, DLNA Server und seit Kurzem Chrome im Kiosk-mode für die Visualisierung. Hardware hab ich den ConBee und enOcean Stick angeschlossen.
Nebenher dient er mir als Zentraler Datei-Server.@mehrwiedu sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Deren Gateway für 150 Öcken kann doch auch nur ein PI im Gehäuse mit Conbee Modul sein, oder?
Ist auch so nur das es RaspBee heisst.
-
@Jey-Cee
Welcher NUC ist es denn von der Ausstattung her. Welches OS hast Du denn dort installiert? Läuft das alles unter Windows oder doch Linux?Ich bin ja auch sehr angetan von diesen Geräten, weil die leistungsmäßig halt viel möglich machen. So ist es ja mit meinem MacMini auch. Da läuft im Prinzip alles an Serversoftware drauf, was bei mir von Relevanz ist, aber leider nicht unter Linux oder Windows laufen kann, weil es macOS getrieben ist.
Nachtrag:
ich habe doch nicht den 3B+, sondern nur den 3B. Vielleicht ist es dort auch die Performance. Ich schaue mir mal die Leistungsunterschiede an und versuche es dann eventuell einfach mit einem neuen PI, falls der Sprung hier groß genug ist. -
@mehrwiedu 3. Generation mit i5, 16GB Ram und SSD. Denke ein aktueller i3 hat die gleiche Leistung wie der i5. Hab Ubuntu Server installiert.
-
Ubuntu wäre mir ja dann schon wieder sympathisch.
Ach ich schau mal.Wie bekommt Ihr eigentlich die Updates auf die Lampen bzw. die Sensoren ohne Herstellergateway?
-
Hab noch nie ein Update gemacht. Warum auch so lange alles Funktioniert.
-
@Jey-Cee sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Hab noch nie ein Update gemacht. Warum auch so lange alles Funktioniert.
Das kann ich nur unterschreiben. "Never touch a running system" - also nur dann Updates machen wenn es dafür einen zwingenden Grund gibt, nicht "weil es besser ist"
A.
-
Hier vielleicht noch ein Code schnipsel von mir bzgl. der Buttonevents. Inkl. Abfrage ob lang oder kurz gedrückt wurde. Läuft bei mir allerdings noch unter deconz 0.4.0.
Steuert die Indoor"Dekolampen" und unsere "OLampen"Gartenlampen. In Abhängigkeit mit einem selbstgebastelten LDR via ESP8266. Daher die Abfrage nach SWRemoteGarten.const Pfad = 'TradfriRemote_1', TradfriRemote = 'deconz.0.Sensor_47.buttonevent', SWRemoteGarten = "javascript." + instance + "." + Pfad + ".SwitchGarten", SWRemoteDeko = "javascript." + instance + "." + Pfad + ".SwitchDekoLicht", OLampe = [ 'sonoff.0.4ch_OutdoorLights.POWER1', 'sonoff.0.4ch_OutdoorLights.POWER2', 'sonoff.0.4ch_OutdoorLights.POWER3', 'sonoff.0.4ch_OutdoorLights.POWER4' ], ILampe = [ 'deconz.0.Light_9.on', 'deconz.0.Light_4.on', 'deconz.0.Light_5.on', 'deconz.0.Light_6.on', 'deconz.0.Light_7.on', 'deconz.0.Light_8.on' ]; createState(SWRemoteGarten, false, { name: "Switch Garten Status", desc: "Gibt an ob das Licht im Garten via Fernbedienung angeschaltet wurde.", type: "boolean" }); createState(SWRemoteDeko, false, { name: "Switch Dekolicht Status", desc: "Gibt an ob das Licht im Garten via Fernbedienung angeschaltet wurde.", type: "boolean" }); on({ id: TradfriRemote, val: 1002 }, function (obj) { console.log(obj.newState.val); ToggleOnOff(); }); on({ id: TradfriRemote, val: 2002 }, function (obj) { console.log(obj.newState.val); KeyDimUp("S"); }); on({ id: TradfriRemote, val: 3002 }, function (obj) { console.log(obj.newState.val); KeyDimDown("S"); }); on({ id: TradfriRemote, val: 4002 }, function (obj) { console.log(obj.newState.val); KeyLeft("S"); }); on({ id: TradfriRemote, val: 5002 }, function (obj) { console.log(obj.newState.val); KeyRight("S"); }); on({ id: TradfriRemote, val: 2001 }, function (obj) { console.log(obj.newState.val); KeyDimUp("L"); }); on({ id: TradfriRemote, val: 3001 }, function (obj) { console.log(obj.newState.val); KeyDimDown("L"); }); on({ id: TradfriRemote, val: 4001 }, function (obj) { console.log(obj.newState.val); KeyLeft("L"); }); on({ id: TradfriRemote, val: 5001 }, function (obj) { console.log(obj.newState.val); KeyRight("L"); }); function ToggleOnOff() { var cnt = 0; for (var i = 0; i < 4; i++) { if (getState(OLampe[i]).val == true) { cnt++; } } if (cnt > 0) { for (var i = 0; i < 4; i++) { if (getState(OLampe[i]).val == true) { setState(OLampe[i], false); } } console.log("Tradfri Garten Remote auf false gesetzt"); setState(SWRemoteGarten, false); } else { for (var i = 0; i < 4; i++) { if (getState(OLampe[i]).val == false) { setState(OLampe[i], true); } } console.log("Tradfri Garten Remote auf true gesetzt"); setState(SWRemoteGarten, true); } } /* function fullOff() { for (var i = 0; i < 4; i++) { setState(OLampe[i], false); } } */ function KeyLeft(val) { var cnt = 0; for (var i = 0; i < 2; i++) { if (getState(ILampe[i]).val == true) { cnt++; } } switch (val) { case "S": if (cnt > 0) { setState(ILampe[0], false); setState(ILampe[1], false); setState(SWRemoteDeko, false); } else { setState(ILampe[0], true); setState(ILampe[1], true); setState(SWRemoteDeko, true); } break; case "L": break; default: console.log("Fehler bei KeyDimUp"); } } function KeyRight(val) { var cnt = 0; for (var i = 2; i < 6; i++) { if (getState(ILampe[i]).val == true) { cnt++; } } switch (val) { case "S": if (cnt > 0) { for (var i = 2; i < 6; i++) { setState(ILampe[i], false); setState(SWRemoteDeko, false); } } else { for (var i = 2; i < 6; i++) { setState(ILampe[i], true); } setState(SWRemoteDeko, true); } break; case "L": if (getState(SWRemoteDeko).val === false) { setState(SWRemoteDeko, true); console.log("Tradfri Remote Deko true gesetzt."); sendFeedback("I", 1); } else { console.log("Tradfri Remote Deko false gesetzt."); setState(SWRemoteDeko, false); sendFeedback("I", 0); } break; default: console.log("Fehler bei KeyDimUp"); } } function KeyDimUp(val) { var cnt = 0; for (var i = 2; i < 4; i++) { if (getState(OLampe[i]).val == true) { cnt++; } } switch (val) { case "S": if (cnt > 0) { setState(OLampe[2], false); setState(OLampe[3], false); setState(SWRemoteGarten, false); } else { setState(OLampe[2], true); setState(OLampe[3], true); setState(SWRemoteGarten, true); } break; case "L": if (getState(SWRemoteGarten).val === false) { console.log("Tradfri Garten Switch eingeschaltet!"); setState(SWRemoteGarten, true); sendFeedback("O", 1); } break; default: console.log("Fehler bei KeyDimUp"); } } function KeyDimDown(val) { var cnt = 0; for (var i = 0; i < 2; i++) { if (getState(OLampe[i]).val == true) { cnt++; } } switch (val) { case "S": if (cnt > 0) { setState(OLampe[0], false); setState(OLampe[1], false); setState(SWRemoteGarten, false); } else { setState(OLampe[0], true); setState(OLampe[1], true); setState(SWRemoteGarten, true); } break; case "L": if (getState(SWRemoteGarten).val === true) { console.log("Tradfri Garten Switch ausgeschaltet!"); setState(SWRemoteGarten, false); sendFeedback("O", 0); } break; default: console.log("Fehler bei KeyDimDown"); } } function sendFeedback(IO, typ) { var ti = null, counter = 0, max = 0; switch (typ) { case 0: max = 4; break; case 1: max = 2; break; default: max = 6; } //clearInterval(ti); ti = setInterval(function () { if (IO == "O") { if (getState(OLampe[0]).val === true) { setState(OLampe[0], false); } else { setState(OLampe[0], true); } } else if (IO == "I") { if (getState(ILampe[2]).val === true) { setState(ILampe[2], false); } else { setState(ILampe[2], true); } } counter++; if (counter >= max) { clearInterval(ti); } }, 1000); } function sleep(milliseconds) { var start = new Date().getTime(); for (var i = 0; i < 1e7; i++) { if ((new Date().getTime() - start) > milliseconds) { break; } } } //function sleep(ms) { // console.log("sleep"); // return new Promise(resolve => setTimeout(resolve, ms)); //} //getState("deconz.0.Raspi-GW.Plug1.reachable"/*reachable*/).val;
-
@Asgothian
@Wildbill
Hallo ihr beiden, ich habe genau dasselbe Problem mit den zwei Stunden Versatz. LastUpdated hängt genau 2 Stunden hinter dera aktuellen Zeit her. Die Uhrzeit im Phoscon passt und in ioBroker auch. Konntest du es inzwischen beheben Wildbill?!
Ich hab mal unter Ereignisse verglichen, da sieht man genau die zwei Stunden Versatz zwischen Objekten und dem echten Änderungsdatum.
-
Nein, aber ich meine im Github-Bereich von Dresden Elektronik hatte ich dazu was gelesen. Da es aber eigentlich für mich eher kosmetischer Natur ist, bin ich dem nicht weiter nachgegangen.
Gruss, Jürgen
-
@Wildbill Ich habs dank dir gerade gefunden. Hab mal noch was dazu geschrieben. Vielleicht wird es ja mal gefixt.
-
Diese zwei Stunden Versatz gibt es aber nur im Adapter. In Phoscon steht die korrekte Uhrzeit.
Ich hatte mich da fast gar nicht getraut das Thema mit der "Sommerzeit" in den Zeitzonen nochmal hochzuholen, und habe mich quasi damit zufrieden gegeben, dass im Adapter genau die aktuell UTC +2 für unsere Zeitzone auf UTC 0 abgeglichen wird.Muss auch damit nichts zutun haben. Kann ja auch sein, dass es nur Sensoren betrifft, die immer noch ans Mainland China gebunden sind. Hier gibt es nämlich nur die 2 Stunden Zeitdifferenz von UTC zu MESZ. Und die sind fix. Unabhängig zu Sommer- oder Normalzeit. Sprich, egal ob wir in UTC +1 (Standarddifferenz zu MESZ) oder UTC +2 (aktuelle Differenz bedingt durch Sommerzeit zu MESZ) hängen.
Auffällig ist aber, dass die gleichen Sensoren am Mijia Gateway den korrekten Timestamp haben.
-
Also bei mir betrifft es alle lastupdated Datenpunkte der Sensoren. Und das sind ein paar Tradfri-Bewegungsmelder, Tradfri-Remotes, ein Tradfri-Dimmer und ein Hue-Dimmer-Switch. Und bei allen sind es exakt zwei Stunden Versatz. Also wohl kein "China-Problem"...
Und ja, in Phoscon sehe ich die korrekte Uhrzeit, ebenso im iobroker, und sowohl auf Host, iobroker-VM und Phoscon-.Raspi mittels date. Und Phoscon oder iobroker laufen bei mir nicht in Docker, da das in dem Github-Issue anscheinend als mögliche Ursache ausgemacht wurde. Also irgendwo baut (vermutlich) die deconz-api 2 Stunden Versatz ein.
Gruss, Jürgen
Gruss, Jürgen
-
@Wildbill
Kannst du mal bitte per web-Browser die rest-api direkt abfragen ? Da steht dann drin welcher Zeitstempel von deconz übertragen wird.A.
(Anleitung wie das geht kann ich erst heute Abend geben) -
Klar, wenn ich es bis heute Abend nicht selbst rausgefunden habe, dann wäre eine kleine Anleitung nicht schlecht...
Gruss, Jürgen
-
Man kann das Log level der Instanz auch auf Debug stellen dann findet man die Ausgaben der API auch im log
-
Das habe ich soeben gemacht und dann eine Hue-FB getestet:
deconz.0 2019-04-18 15:53:36.020 debug Websocket message: {"e":"changed","id":"7","r":"sensors","state":{"buttonevent":4002,"lastupdated":"2019-04-18T13:53:36"},"t":"event","uniqueid":"00:17:88:01:04:af:d5:63-02-fc00"}
Da kommen also auch schon zwei Stunden Versatz an...
Gruss, Jürgen
-
Hier im Thread zum deconz-rest-plugin auf Github gab es nun die Aussage, dass die API die Zeiten grundsätzlich in UTC ausgibt, was die zwei Stunden erklären würde. Somit wundert es mich nun eher, wenn doch bei jemandem die MESZ als lastupdated steht?!
Kann da jemand sagen, dass bei ihm die lokale Sommerzeit ankommt?Gruss, Jürgen