[Aufruf] deConz Adapter Testen 1.1.2
-
@mehrwiedu sagte in [Aufruf] deConz Adapter Testen 1.0.2:
In der Phoscon App hatte ich schon versucht die Idee mit den Seitentasten als Ein/Aus Taste umzusetzen, bekam allerdings die zweite Gruppe an Lampen nicht in eine Szene.
auch das geht. Du kannst die gleiche Fernbedienung in 2 Gruppen nutzen, u d jeweils in der Gruppe nur die gewünschten Tasten belegen.
A.
-
@paul53 sagte in [Aufruf] deConz Adapter Testen 1.0.2:
@mehrwiedu sagte:
1 x kurzer Klick mittlere Taste AN und AUS Esszimmer und mit der gleichen Fernbedienung 1 x langer Klick AN und AUS Wohnzimmer?
Mittels Javascript ist (fast) alles möglich.
Wieder ein Grund mehr, mich tiefer in die Materie einzuarbeiten...ich weiß.
Wenn ich nur so viel Zeit hätte wie Arbeit. Hehe...;)Wobei ich mich grad selbst ausgetrickst habe mit der Tastenbelegung in der Phoscon App. Ich habe noch die Tradfri Logik des Gateways verinnerlicht. Jede Lampe (Gruppe) mindestens ein Steuergerät. Daher haben Esszimmer und Wohnzimmer jeweils eines. Voll blöd. Ich spare mir jetzt die FB vom Esszimmer (wir haben ein Wohn-/Esszimmer), lege die Lampengruppe auch auf die Wohnzimmerfernbedienung und erstelle einzelne Szenen, somit kann ich AN/AUS der zweiten Gruppe auf die Seitentaste legen.
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
@mehrwiedu sagte in [Aufruf] deConz Adapter Testen 1.0.2:
In der Phoscon App hatte ich schon versucht die Idee mit den Seitentasten als Ein/Aus Taste umzusetzen, bekam allerdings die zweite Gruppe an Lampen nicht in eine Szene.
auch das geht. Du kannst die gleiche Fernbedienung in 2 Gruppen nutzen, u d jeweils in der Gruppe nur die gewünschten Tasten belegen.
A.
Oder so rum...Hahaha...ich bin noch nicht im deConz angekommen. Na klar. Entweder die zwei Gruppen Lampen auf eine Fernbedienung oder die Fernbedienung jeweils an den Gruppen.
-
So. Nach einem langen Wochenende der Einrichtung, des Testen und der Umsetzung Eurer stets super hilfreichen Unterstützung (vielen Dank dafür), bin ich zu dem Schluss gekommen, dass ich den Stick zwar behalten werde, da mich die Software und das Zusammenspiel mit ioBroker überzeugt hat, ich jedoch eine andere Hardwareplattform anstelle des PI benötige.
Mit dem Raspberry werde ich hier auf Dauer nicht glücklich werden. Alles, was nach der Einrichtung gestern noch sehr performant funktionierte, ist heute nur mit Mühe und Not zur Ausführung zu bringen. Tasten müssen teils 5x gedrückt werden, oder es braucht bis zu 10 Sekunden, bis sie überhaupt reagieren und ein Licht schalten. Dazu ist er gestern auch kurz einmal eingefroren und verlangte nach einem Neustart.
Da mein ioBroker in einer macOS Umgebung läuft, kann ich den Stick dort nicht einbinden. Aus dem Docker auf der Synology habe ich ioBroker erst vor einiger Zeit verbannt, so dass ich jetzt nicht schon wieder die Synology nur für den Stick dazu nutzen möchte.
Also läuft es wohl darauf hinaus, dass ich mir k. A. einen Mini-PC oder einen NUC dafür anschaffe. Das wollte ich zwar vermeiden, aber wenn ich nach einem Tag den Raspi schon neustarten muss, damit ich überhaupt mein Licht mittels Taster schalten kann, dann ist das wohl so. Meint Ihr, mit etwas mehr Power läuft das stabiler? Oder sollte ich tatsächlich noch eine ioBroker Instanz (Multihost) dazu einrichten, die dann nur für die Zigbee Adapter zuständig ist?
Hat wer andere Erfahrungen, oder kann mir hier noch Tipps geben, wie ich den Raspi eventuell doch optimieren kann?
Habe den wie bereits beschrieben für die Einrichtung und das Flashen meiner Gosund Steckdosen mit einem Raspbian Strech Lite bestückt, was bisher auch keine Probleme gemacht hat. Nun für den Conbee habe ich die Pakete installiert und dem Strech Lite eine GUI verpasst. So wie ich das jetzt teilweise gelesen habe, hätte das auch nicht sein müssen, wenn der eh headless betrieben wird und per VNC visualisiert wird. Anders herum brauche ich auch die grafische Darstellung der Verbindungen in der deConz Software nicht unbedingt. Oder doch?Was mich jetzt etwas von einem zusätzlichen System als Alternative zum Raspi abhält, ist die Tatsache, dass ich dann auch meine Hauptinstanz von ioBroker problemlos auf einem NUC laufen lassen kann. Hier bin ich allerdings überaus zufrieden mit dem MacMini und der hat eh auch noch andere Dienste im Bauch, die ich nicht einfach abschalten kann.
Außerdem habe ich mir jetzt erst fürs macOS schweineteure Touchtreiber gekauft um die Visualisierung zu verwirklichen.
Gut, wäre Lehrgeld. Was sagt ihr? Müsste deConz eigentlich geschmeidig performant auf dem Raspi laufen, oder ist das eine Engstelle? Sonst würde ich auch nochmal einen Cleaninstall machen auf Basis Eurer Empfehlungen und mir notfalls einen neuen Raspi oder ne SSD dafür holen, da der jetzige doch schon einige Jährchen auf dem Buckel hat und ich mit diesen SD Karten eh auf dem Kriegsfuß stehe.
-
@mehrwiedu
Die grafische Oberfläche ist für die Nutzung von deconz nicht notwendig. Ich betreibe deconz ohne Probleme auf einem raspi 3b+ und habe kaum / keine Verzögerung der Aktionen erkennbar ist.Ich habe aber auch alles andere von dem raspi entfernt.
A.
-
@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
