Beiträge von Seven of Nine

Zitat von BGrosse

Sag mal, bist Du eigentlich Shelly Tester oder wie kriegt man so nen Footer hin...?

ja, da sind zwar auch selbstgekaufte, aber eben auch ein paar "gesponsorte" Geräte von Allterco dabei.. 24 Stück + diverse Zubehörteile sind grad noch unterwegs

Dafür "muss" ich testen, testen, testen und nochmals testen ..

Zitat von BGrosse

P.S.: Wie kriegt man hier überhaupt nen Footer hin?

oben im Kontrol unter Benutzerkonto - letzer Punkt.

Zitat

DiskStation laufen und das ganze hängt ein einer FB 7490.

Wie ist denn dein Netzwerk vom HA (Docker Container?) auf der Diskstation eingerichtet? Host, Bridge oder MACVLAN?

BGrosse nimm mal die Batterie raus und direkt wieder rein.. mein D&W2 sendet jetzt richtige Meldungen.. Igor vom QA Team hat es gegengetestet und sein D&W2 macht was er soll.. ich hab daraufhin bei meinem die Batterie raus und wieder reingemacht, jetzt sendet er korrekt

-1 ist der Standard-Wert, wenn Tilt deaktiviert ist..

Zitat von BGrosse

dass das OpenHAB Binding diesen Wert einfach ignoriert und gar nicht erst "durchlässt"...?

würde ich mal vermuten, da OH davon ausgehen wird, dass der Sensor deaktiviert ist.

so, nach ersten Tests sieht es so aus, als wenn der D&W2 einen Bug hat, das Coap-Payload [0,3109,-1] meldet den Tilt-Sensor grundsätzlich mit -1.

Hab es im QA Bereich gemeldet, warte aktuell noch auf Validierung durch ein weiteres QA Team-Mitglied.. danach erstelle ich einen Bug-Report und dann ist es mit ziemlicher Sicherheit spätestens im nächsten Firmware-Update gefixt..

Zitat von BGrosse

Parallel im OpenHab Log erscheinen ebenfalls alle Änderungen bzgl. Illumination, Lux, Temperatur und Reed Kontakt - nur eben KEIN Tilt.

dann spricht das für einen Bug im OpenHAB Binding (oder den lokalen Coap-Nachrichten).. kann ich eventuell später mal testen, ob es am Shelly liegt.

Zitat von Seven of Nine

Ansonsten über diesen Weg probieren:

Probleme Einbindung ins WLAN-Heimnetzwerk

Hast du es denn darüber mal probiert? Link siehe etwas weiter oben (beim Zietieren gehen die leider verloren).

Aktivieren muss nicht zwingend bedeuten, dass es besser wird Es kann auch genau das Gegenteil bewirken, deshalb unbedingt im Hinterkopf behalten.

Wichtig wäre halt der Cloud-Test, da man damit sehen kann ob der Shelly tatsächlich ein Problem hat.

Alternativ könnte man es mittels MQTT (nutzt TCP statt UDP-Verbindungen) oder Actions (nutzen ebenfalls TCP statt UDP) direkt im Shelly testen, falls du im OpenHAB entsprechende Configs hast..

Dann wird das Hinzufügen auch geklappt haben und der Shelly ist in der FritzBox unter Heimnetz - Netzwerk sichtbar, oder?

dann wird der Shelly vermutlich nicht richtig eingefügt..

Bei den Zugangsdaten (SSID und zugehöriges Passwort) bist du zu 100% sicher?

(Es gab schon häufiger mal den Fall, dass jemand statt des SSID-Passworts das Passwort vom FritzBox-Login verwedet hat)

Ansonsten über diesen Weg probieren:

Probleme Einbindung ins WLAN-Heimnetzwerk

Zitat von harryheizer

habe aber gerade den Repeater abgezogen und es nochmal ohne probiert -gleiches Ergebnis

Danach einen vollwertigen Reset vom Shelly probiert? also strom weg, dann wieder an und 5x mit dem Shalter an/aus, so dass das Relais klackert..

Zitat von BGrosse

Also ich hab ne FritzBox 7490 und nichts speziell konfiguriert an Blacklists, Whitelists, Gerätefiltern o.ä. Was könnte ich da noch prüfen?

das (weil es sich auf UDP Multicast-Nachrichten auswirkt) hier könnnte z.B. Einfluß darauf haben:

Deswegen wäre es eben so wichtig, es zunächst mal mit der Shelly.Cloud zu testen. Damit könnte man dann zumindest eingrenzen, ob der DW2 tatsächlich eine Macke hat oder eben dein Netzwerk die Ursache ist..

Mit einem Amazon Echo(Alexa ) geht das..

[media]https://www.youtube.com/watch?v=Jcl6eHQpZiM[/media]

Mit Google Home aber nicht.

Zitat von BGrosse

, Cloud nutze ich generell nicht, bei mir läuft alles in mein lokales System - OpenHAB.

ok, aber diesen speziellen DW2 hattest du auch mit der Shelly.Cloud explizit getestet? wenn der nicht sendet, müsste er spätestens nach 24 Stunden als "Offline" in der Shelly.Cloud auftauchen.

OpenHAB arbeitet über CoAp (UDP Multicast-Nachrichten), da kann es durchaus sein, dass deine Netzwerk-Infrastruktur die Nachrichten filtert / falsch gruppiert und möglicherweise nicht zum OH-Server durchlässt.. und das passiert dann nicht zwangsweise mit allen Geräten sondern durchaus auch mal nur mit einem einzelnen Shelly.

Daher wäre es sehr wichtig, dass du das explizit mit der Shelly-Cloud testest.. Ausreichend WLAN-Empfang an der Stelle, wo er montiert ist, hat er aber?

Zitat von BGrosse

warum der neue jetzt zwar aufwacht und alles schickt, aber den Winkel nicht.

Den Tilt-Sensor hattest du aber kalibriert?

mhh, du drückst so kurz, dass der InputEventCnt nicht hochgezählt wird? dann hatte der Schalter vermutlich gar keinen Kontakt und da kommt lediglich ein Coap-Status-Event..

Du kannst ja mal probeweise die regulären Status-Nachrichten (kommen eigentlich alle 15 Sekunden) hochsetzen, dann irritieren sie nicht bei der Fehleranalyse.

.../settings?coiot_update_period=600 (normal wäre 15 statt der 600)

Na guck, kaum macht man es richtig klappts auch

Einen tatsächlichen Bug gibt es in dem Verfahren aktuell aber trotzdem:

RE: Shelly Button1 und ioBroker

Aber den wirst du beim Shelly1 oder IX3 vermutlich nicht (oder nur nach einem Reboot) merken..

ich hab in den letzten zwei Tagen damit rumexperimentiert und kann den Fehler, der beim Button1 auftritt nachvollziehen jetzt sogar mit einem anderen Shelly (i3, Shelly1) problemlos nachstellen.

Konkret passiert folgendes:

Die Theorie: man drückt den Button/Schalter, der Shelly wacht auf und schickt zwei Coap-Nachrichten.

die erste enthält den beim InputEventCnt den initalen (oder alten) Wert, die zweite einen un 1 höheren Wert.

Die Praxis: man drückt den Button/Schalter, der Shelly wacht auf und sicht zwei Coap-Nachrichten. Beide enthalten den gleichen alten Wert. Drückt man, solange der ShellyButton1 noch wach ist, weitere Male auf den Knopf funktioniert es, also InputEventCnt wird um 1 erhöht.

Wenn man einen Shelly1, IX3 etc. rebootet und dann direkt den Taster drückt, passiert exakt das Gleiche.

Die ersten zwei Coap-Nachrichten haben beide den Wert 1 beim InputEventCnt. Ab dann funktioniert es reibungslos.

Beim Button1 ist es deshalb so problematisch, weil der in den DeepSleep geht und der Counter dabei immer wieder auf den initialen Wert zurückgesetzt wird (Volatile Memory)..

Ich gehe mal davon aus, dass da ein initialer Counter falsch gesetzt ist und statt 0 eine 1 (oder umgekehrt) gesetzt wurde.

Das hab ich heute Morgen dem Chef-Entwickler so geschrieben. Ich hoffe, dass es hilft und der Fehler dann doch mal beseitigt werden kann.

Denn das ist ein genereller Fehler, der eigentlich alle Shellys betrifft, aber bei anderen Shellys eben (weil sie sich nicht schlafen legen) nur sehr schwer auffällt.

Edit: auch mein eigener Code enthält manachmal Fehler

alle anderen Shellys machen es richtig und starten mit 0 anstelle von 1.

Der Fehler im Button1 ist aber trotzdem vorhanden: nach dem DeepSleep startet der Button1 mit 1 statt 0 beim InputEventCnt.

ich hab in den letzten zwei Tagen damit rumexperimentiert und kann den Fehler, der beim Button1 auftritt jetzt sogar mit einem anderen Shelly (i3, Shelly1) problemlos nachstellen.

Konkret passiert folgendes:

Die Theorie: man drückt den Button/Schalter, der Shelly wacht auf und schickt zwei Coap-Nachrichten.

die erste enthält den beim InputEventCnt den initalen (oder alten) Wert, die zweite einen un 1 höheren Wert.

Die Praxis: man drückt den Button/Schalter, der Shelly wacht auf und sicht zwei Coap-Nachrichten. Beide enthalten den gleichen alten Wert. Drückt man, solange der ShellyButton1 noch wach ist, weitere Male auf den Knopf funktioniert es, also InputEventCnt wird um 1 erhöht.

Wenn man einen Shelly1, IX3 etc. rebootet und dann direkt den Taster drückt, passiert exakt das Gleiche.

Die ersten zwei Coap-Nachrichten haben beide den Wert 1 beim InputEventCnt. Ab dann funktioniert es reibungslos.

Beim Button1 ist es deshalb so problematisch, weil der in den DeepSleep geht und der Counter dabei immer wieder auf den initialen Wert zurückgesetzt wird (Volatile Memory)..

Ich gehe mal davon aus, dass da ein initialer Counter falsch gesetzt ist und statt 0 eine 1 (oder umgekehrt) gesetzt wurde.

Das hab ich heute Morgen dem Chef-Entwickler so geschrieben. Ich hoffe, dass es hilft und der Fehler dann doch mal beseitigt werden kann.

Denn das ist ein genereller Fehler, der eigentlich alle Shellys betrifft, aber bei anderen Shellys eben (weil sie sich nicht schlafen legen) nur sehr schwer auffällt.

da bin ich wohin übermittelt der DW2 denn keine Daten?

An die Cloud oder an OpenHAB? wenn nur OpenHAB betroffen ist bitte mal testweise die Cloud aktiveren (für ein paar Stunden) und dann gucken, ob das funktioniert.

Laut Datenblatt vom Hersteller kann der sowohl Phasenanshnitt als auch Abschnitt..

https://www.halemeier.de/fileadmin/temp…_12V_KAT_DE.pdf

ist der ShellyDimmer kalibriert? (Settings - Calibration)

- Hast du neben der Fritzbox weitere Komponenten (Repeater, AccessPoints) im Einsatz?

- wenn ja:

- welche? (Hersteller, Modell)

- wie sind die mit der Fritzbox verbunden (Kabel, WLAN)

- Tauchen im FritzBox-Fehlerprotokoll Meldungen auf?

(System - Ereignisse - WLAN zusätzlich den Haken für fehlerhafte Anmeldungen setzen).

Zitat von showa

Noch eine Frage soll man für die Shellys eine feste IP Adresse Festlegen.

nein, es gibt keinen Grund für eine feste IP:

RE: Einsteiger-Empfehlung: DHCP statt static IP

Zitat von funkenwerner

kann die Reaktionszeit verbessern

Sorry Werner, (ich schätze deine Elektro-Fachkompetenz sehr ) aber das ist kompletter Unfug..

Die Reaktionsgeschwindigkeit zwischen zwei Netzwerk-Teilnehmern (meine Netzwerker-Kollegen sagen Latency dazu) hat absolut nichts damit zu tun, wie das jeweilige Gerät seine IP-Adresse bezogen hat.