Beiträge von dylan_09

Hallo,

Zitat

also ich hab Pin 3 (weiß) des Shelly Uni mit Klemme 7 am HTS 711-01 (NICHT HTC... Sorry, hatte mich oben verschrieben) verbunden und Pin 7 (grün) mit Klemme 1.

Ob das mittel- bis langfristig jedoch gut ist, weiß ich nicht, da ich gerade noch mal gemessen habe:

Ohne Shelly Uni messe ich 17,59V an Klemme 7 (+) gegen Klemme 1 (-), mit angeschlossenem ADC_IN nur noch 14,26V Ruhespannung am HTS 711-01.

gibt es mit dem UNI an der Siedle Anlage bei dir schon Langzeit Erfahrungen? Ich habe das kürzlich auch so realisiert.

Der Siedle 1+N Bus signalisiert die Zustände durch verschiedene Spannungspegel zwischen Kl. 7 und Kl. 1:

• 18 Volt ist der Ruhezustand (hast du ja ohne den UNI auch gemessen)
• Wird der Klingeltaster gedrückt, steigt die Spannung auf > 20 Volt an.
• Direkt danach sinkt sie auf ca. 15 Volt ab. Diese bleibt für ca. 30 Sekunden bestehen, bevor sie wieder auf 18 Volt für den Ruhezustand steigt.

Mit dem Shelly UNI an Kl. 7 und 1 schafft die Siedle Anlage es nicht, den Pegel wieder auf 18 Volt zu heben. Einziger Nachteil, den ich bisher finden konnte:

Das HT ist permanent aktiv und es kann nach abheben des Hörers mit dem TLM kommuniziert werden. Und der TÖ ist auch permanent aktiv. Ohne den Shelly UNI wird das nach ca. 30 Sekunden durch anheben des Pegels auf 18V gesperrt. Da es nur eine 1 Teilnehmer Anlage ist halte ich das für OK.

Oder übersehe ich etwas elementares?

Ulrich

Ich habe selber einen Infrarot Strahler mit einer Philips Röhre. Und kann auch nur dazu raten, den Anlaufstrom zu begrenzen. Wir verwenden für unsere sogar einen Dimmer um die Wärmemenge zu regulieren. Sehr angenehm nicht immer mit voller Leistung zu Heizen.

Hi,

I only had this with one of my Shelly 2.5. Had a few problems with WLAN connection.

When this happened, I get "status: offline" via Mosquitto MQTT broker.

Interestingly the Shelly did start sending MQTT messages (temp, current, voltage, ...) after a few minutes. But the state tag gets updated to "online" only once in an hour (default in Shelly MQTT settings).

I have a support ticket open since beginning of august. After a few request messages in alterco ticket system I triggered someone at Alterco through facebook group. And since yesterday the developers are investigating.

Maybe you could check if the Shelly are sending there MQTT tags but the state is set to offline. As long as the state is offline, Home Assistant mark him also as offline.

Hallo,

kurze Rückmeldung zu dem Thema. Ich habe heraus gefunden, wie die DNS Anfrage aufhören, bzw. was der Shelly tut:

Seven of Nine hatte das Thema Zeitzone ja schon mal angesprochen.

Zitat

wenn dein Shelly keine TimeZone-Settings abrufen kann könnte das die Ursache sein..

Im Webinterface auf manuelle Zeitzone einstellen, zusätzlich einen lokalen NTP-Server konfigurieren..

War in den Settings auch alles so konfiguriert. Allerdings Konfiguration über HTTP API. Gestern war ich nach langer Zeit mal wieder in der Web GUI und habe dort die Timezone und Location settings kontrolliert.

Manuelle Zeitzone: Check, NTP Server: Check

Bei der Einstellung Auto DST taucht dort als Anmerkung "Internetverbindung notwendig" auf.

Und das Flag ist gesetzt. Wird auch in meinen Scripten, die die Shelly per HTTP API konfigurieren bei der Neukonfiguration gesetzt.

In der Common HTTP API Dokumentation geschaut: Und da fehlt die Anmerkung.

In allen Shelly das Flag ausgeschaltet. Und Ruhe ist.

Weiss nicht ob es ein Fall von PEBCAK oder fehlender/mangelhafter Doku ist...

Hallo,

deinen Vorschlag mit dem eigenen Update Server hatte ich seinerzeit schon einmal versucht umzusetzen. DNS Eintrag auf eignen nginx Server. Aber das hat nicht geholfen. Ich lkonnte auf die Schnelle nicht heraus finden, was der Shelly als Antwort erwartet. Mit meinen Versuchen war er nicht zufrieden. Und dann hat mir die Zeit gefehlt, zu forschen, was der Shelly dort als Antwort erwartet.

Nerven nicht unbedingt. Aber ärgerlich, das damit meine PiHole Logs geflutet werden. Bei ca 30 Shelly sind das mal eben 40.000 Einträge in den Logs am Tag. Da dann nach den relevanten Infos filtern macht keinen Spass.

Und laut Support sollte das nicht so sein.

ESPHome oder Tasmota sind dann der letzte Ausweg. Aktuell bemüht sich der Support ja noch.

Mal ein Zwischenstand im Austausch mit dem Support. Da geht es ja bereits einige Zeit hin und her. Da ist Allterco sehr vorbildlich. Kommunikation immer freundlich und sehr schnell

Aber die DNS Anfragen/IP Verbindungsaufbau scheint ein echtes Problem in der Shelly FW zu sein. Die Liste der Ideen und Versuche, die mir vom Support vorgeschlagen wurden ist schon teilweise recht abenteuerlich. Und bei jeder Beta/Release Version sollte ein Fix enthalten sein.

Fakt ist wohl: Die Shelly versuchen eine Verbindung zu "api.shelly.cloud" herzustellen. Kommt diese nicht zustande, wiederholen sie das ca. alle 60 Sekunden.

Zeit über ESPHome oder Tasmota nachzudenken... Wenn es nicht so viel Aufwand wäre...

Ein paar Tage gebe ich Alterco noch.

Zitat

Nein habe ich nicht. Da ich wahrscheinlich diesbezüglich nicht der erste bin, werde ich bei den Entwicklern bzw. beim Hersteller auf taube Ohren stossen.

Nö. Wirst du nicht. Bin gerade in Kontakt mit Support und Entwicklung. Und das verhalten ist so nicht gewollt. Ab und an (von mir aus alle 2 Stunden) darf er gern mal einen DNS Request und Anfrage nach aussen stellen.

Minütlich ist etwas heftig. Traffic im WLAN ist das eine... Unschön. Sollte APs und Router aber nicht ins schwitzen bringen.

Blöd ist das es die Logs meines Pi-Holes flutet. Da ist nix mehr mit vernünftig auswerten auf dem Pi4. Von meinen ca. 30-35 Shelly machen das fast alle (nach Installation von 1.10.1) werden es weniger. Sind dann aber immer noch > 20.000 Einträge in den Logs.

Allterco ist dran. Und ich bin wohl nicht der erste, der mit dem Problem an sie heran getreten ist. Dauert jetzt aber ein paar Tage, weil ich für weitere Tests ein paar der Shelly flashen muss. Das wird leider nix dieses WE.

An dem Punkt bin ich auch gerade mit dem Shelly Support dran. Alle meine Shelly testen anscheinend regelmäßig (minütlich) auf updates.

Interessant ist, das sie wohl minütlich eine DNS Query für api.shelly.cloud machen. Aber im Firewall Log tauchen nicht unbedingt minütlich Zugriffe auf (da traue ich aber den Unifi Logs nicht über den Weg).

Hier wurde das schon von mir angesprochen.

Die Shelly sind eingesperrt. Raus kommen sie nicht. Aber leider versauen sie mir die DNS Statistik Gut. Die ist nicht so wichtig.

Aber nachdem dort ca. 30 Shelly minütlich Anfragen hin schicken sind die Query Logs natürlich vollkommen voll gemüllt. Sobald ich etwas neues vom Support habe, melde ich mich.

Das ist nicht der Grund. TimeZone und Geo Location sind manuell eingestellt.

Lokaler NTP Server ist auch konfiguriert. Und funktioniert. Nach Neustart hol er sich dort die aktuelle Zeit.

Der Hinweis mit den Abfragen, die der Shelly auf api.shelly.cloud abschickt, war nur Informativ. Oder als Erinnerung für nicht

Müsste man halt alles implementieren, um einen lokalen Update Server zu bauen.

Gestern Abend etwas mit der Konfiguration bzw. den DNS und Update-Anfragen der Shelly experimentiert:

1. Auch wenn die DNS Abfragen nicht blockiert oder auf 0.0.0.0 umgebogen werden, versuchen die Shelly sehr häufig eine Verbindung aufzubauen. Teilweise habe ich in den Logs Intervalle von 30 sec gefunden.

2. Umbiegen auf einen lokalen Server (der erstmal eine Fehlermeldung 404 liefert) ändert daran nix.

Abgefragt werde die TimeZone Settings und die Informationen, ob Updates vorhanden sind.

Leider gerade keine Zeit, mal zu testen, ob das auch lokal vorgehalten werden kann.

Zumal es eigentlich nur ein "Schönheitsproblem" ist. Und sich die Frage stellt, warum das Abfrage Intervall für Updates so extrem kurz ist??

Zitat

http://api.shelly.cloud auf einen lokal vorhandenen Webserver zeigen lassen und da sein eigenes Firmware-Repo hosten, sollte ebenfalls klappen

http://api.shelly.cloud/files/firmware ist meines Wissens das JSON, welches die Shelly abrufen.

Danke. Das ist ein guter Typ. Mal wieder den Wald vor lauter Bäumen nicht gesehen.

Und dann lässt sich sogar die Update Routine noch vereinfachen. Aktuell packe ich die FW auf den lokalen nGinx Server und stoße das Update manuell per Batch mit einem curl Aufruf pro Device an.

Nun kommt noch das JSON mit den dann lokal vorhanden Versionen auf den nGinx und die Shelly können sich die Updates selber ziehen.

Batch Script weg und das ganze als Automatisierung von Node-Red per MQTT an den Shelly Bin mal gespannt, ob das funktioniert!?

Danke für den Tipp und den Anstupser. Wenn es nicht passt, schaue ich mal ob die DNS Anfragen weniger werden, wenn der Shelly sie auflösen kann.

Vielen Dank

Anfrage ob Updates verfügbar sind? Haben ja erst einmal mit "Cloud" nix zu tun.

Sie dürfen das ja auch alles kennen. Was aber etwas stört, ist das sehr kurze Intervall der Abfragen. In der DNS Blocklist liegen die Shelly bei mir ganz weit vorn in der Statistik der geblockten Zugriffe.

Hallo,

gibt es eine Einstellung, die das Intervall für DNS / Update Anfragen der Shelly verlängert?

Meine Shelly (1, 1L, 2.5, Dimmer2, Plug S) schicken in sehr kurzen Intervallen Anfragen an z.B. den DNS Server (suche nach api.shelly.cloud, ...). Teilweise bis zu 2 mal pro Sekunde. Wahrscheinlich der Update check würde ich vermuten.

Die DNS Anfrage wird im PiHole geblockt/umgeleitet. Aber es its natürlich WLAN Traffic, der sich mit zunehmender Anzahl Geräte auch summiert.

Die Shelly sind für MQTT konfiguriert. Gegenstelle Eclipse-Mosquitto. Also Cloud automatisch deaktiviert.

Wie bereits erwähnt, DNS Anfragen auf api.shelly.cloud, ... geblockt. Und alle Zugriffe auf externe IPs in der Firewall geblockt.

Habe bereits auf der Shelly Homepage in der Dokumentation gesucht ob es dort eine Option / Einstellung per RestAPI, WebRequest oder ähnliches gibt, um das Intervall zu verlängern.

Gibt es eine Möglichkeit im Shelly diese doch sehr häufigen Anfragen zu unterbinden / abzuschalten?

Ulrich