Genau, das ist mir danach eingefallen.
seltsamerweise wird der Code 200 zurückgegeben, aber Gladys gibt einen Fehler aus (also keine Variable zum Wiederverwenden).
Okay, also das Verwenden von geschweiften Klammern außerhalb von Variablen verursacht den Fehler. Ich aktualisiere das GitHub-Ticket.
@lmilcent Eigentlich kommt der Fehler daher, dass wir die Arrays in den Antworten nicht korrekt verwaltet haben, die Parsing-Funktion behandelte nur Objekte.
Ich habe einen PR erstellt, der das Problem behebt:
Hast du eine DEV-Umgebung zum Testen?
Falls nicht, kannst du in der Zwischenzeit die Math.js-API mit einem einfachen String anstelle eines Arrays verwenden, und das funktioniert gut ![]()
Was ich bei meinen Tests beobachtet habe:
Bei mir funktioniert es so ![]()
Das ist die Methode, die ich anschließend verwendet habe. Aber bei mir funktioniert es nicht mit der aktuellen Version von Gladys.
Ich habe kein besonderes Testumfeld, ich nutze direkt meine Produktion, indem ich meine Datenbank vorher sichere.
Falls ein Fehler auftritt, stelle ich die Datenbank wieder her und gehe zur stabilen Version zurück ![]()
Es handelt sich nicht um einen kritischen Dienst, also kann ich mir das leisten!
Ach ja, es gab tatsächlich noch einen anderen Bug, die Attribute, die als « null » zurückgegeben werden, haben die Generierung der Variablen zum Absturz gebracht
Man muss also auf das Update warten.
Ok, ich sprach eher von einer Entwicklungsumgebung (so etwas wie auf deinem Laptop, um Pull Requests testen zu können)
Macht nichts, ich werde selbst ausführlich mit der API von Math.js testen und das wird in der nächsten Version von Gladys landen (nicht die, die du heute siehst)
Ich hatte damit angefangen, mir eine zu erstellen, aber das Problem bestand beim Zigbee-Service. Ohne Adapter konnte ich ihn nicht mit den Daten meiner DB verwenden (um Tests mit echten Daten durchzuführen).
Gibt es einen Trick, um einen Adapter zu simulieren, Zigbee2MQTT nicht zu starten, aber dennoch die Daten in der DB zu verwenden?
Das hängt davon ab, was du testen möchtest. Für das Testen von PRs in Bezug auf Zigbee2mqtt wird es nicht einfach sein. Aber für das Testen von Dingen, die den Core betreffen, brauchst du keine Dienste. Ich nutze oft den lokalen MQTT-Dienst zum Testen, ich sende Werte an einen lokalen Mosquitto (ich nutze https://mqttx.app/), erstelle mir ein kleines Dashboard, und das reicht, um die meisten Core-Entwicklungen zu testen!
Falls du mit deiner DB testen möchtest, damit es keinen Einfluss auf deine Produktion hat, musst du alles, was mit Gladys Plus verbunden ist, deaktivieren, damit es sich nicht anstelle deiner Produktion verbindet.
Normalerweise, wenn ich eine DB eines Benutzers laden möchte, lösche ich vor dem Starten von Gladys die Tabelle t_variable, die alle Anmeldedaten aller Dienste speichert. So bin ich sicher, dass eine Testinstanz nicht wirklich die Dienste des Benutzers kontaktiert (Kalender, Gladys Plus, etc…).
Danke für die Info! Daran hätte ich nicht gedacht.
Z2m unterstützt TCP über ser2net, ich werde mich bald darum kümmern. Ich weiß nicht, ob @spenceur es getestet hat
Damit kann der Dongle über das Netzwerk verfügbar gemacht werden
Das klingt vielversprechend!
Hallo @VonOx, wäre diese Lösung von z2m über ser2net, um den Dongle über das Netzwerk verfügbar zu machen, mit WSL kompatibel? Denn WSL erkennt keine USB-Ports…
Eine weitere Frage: Kann ein Sensor von mehreren z2m-Dongles (z. B. Sonoff) verfolgt werden?
Wie oben erwähnt, habe ich es noch nicht getestet, aber ich denke schon.
Die Zigbee-Geräte sind mit einem Dongle gepaart. Das ist exklusiv.
Eine andere Lösung, die wir oft angesprochen haben, wäre die Möglichkeit, sich mit einem entfernten MQTT auf der Z2M-Integration zu verbinden. Dadurch könnte man sich mit einem Z2M auf einem entfernten Pi verbinden und sehen, was das auf einer Entwicklerversion von Gladys ergibt.
@lmilcent Nur zur Info, ich bin heute bezüglich deines Bugs mit der HTTP-Anfrage an Mathjs weitergekommen. Das war nicht einfach, denn ich musste das vom Frontend verwendete Format für die Variablen ändern, um Arrays zu verwalten, und dabei mit dem Bestehenden und den verschiedenen „Verbrauchern“ dieser Variablen kompatibel bleiben: dem Block ‹ message › und dem Block ‹ nur fortsetzen, wenn ›.
Ich habe die letzte Version auf meine PR gepusht, ich mache am Montag weiter (es ist hier 19 Uhr
).
Falls du dieses Wochenende daran herumspielen und sicherstellen möchtest, dass es funktioniert, kannst du dir eine kleine Entwicklungsumgebung poppen lassen. Es ist nicht nötig, deine DB zu importieren, da es nur in den Szenen ist. Du erstellst einfach eine neue Szene ![]()
Danke dir und ein schönes Wochenende, genieße es gut!
Zur Info, ich habe den PR gemerged, der das Problem mit der Math.js-API behebt. Das wird in der nächsten Version von Gladys enthalten sein!
Vielen Dank ![]()
Ich kann mir eine Szene erstellen, die eine Art Mittelwertberechnung verwendet, bis Gladys dies unterstützt.
Anwendungsfall
Mich benachrichtigen, wenn sich mein Kühlschrank erwärmt:
Den Wert des Kühlschranksensors alle 30 Minuten für 2 Stunden abrufen und mich benachrichtigen, wenn der Durchschnitt dieser Werte über einem Schwellenwert liegt.
(nur im Sommer) Mich benachrichtigen, wenn ich meine Wohnung lüfte, aber sie beginnt, sich zu erwärmen:
Wenn der Durchschnitt der Temperaturen in meinem Wohnzimmer und Esszimmer nahe, gleich oder höher als die Außentemperatur ist, mich daran erinnern, die Fenster zu schließen.
Getestet und abgesegnet (https://gladys-new-device-name.netlify.app/) !
Praktisch Gladys Plus, um reine Frontend-Fixes zu testen ![]()
Absolut ![]()
Keine Entwicklungsumgebung auf Benutzerseite nötig!