Beiträge von Jo_Be

Zitat von tvbshelly

Nameserver to use when ipv4mode is static

Das ist schade, wäre ein Eintrag doch auch bei per DHCP empfangenem DNS-Server ohne weiteres möglich. Aber sei's drum, ist halt Shellys Entscheidung dies nicht bei GetStatus anzuzeigen.

Zitat von Schubbie

da man sich damit einen Loop erzeugt

Nö. Wer das denkt, hat's nicht verstanden.

Zitat von Yankee

Jedoch nicht den ['wifi']['sta']['nameserver'] = '', der ist tatsächlich bei allen leer.

Ist das ein Phänomen nur in meinem Netzwerk oder kann jemand bestätigen, dass die Shellys bei DHCP tatsächlich nicht die IP des Nameserver setzen/speichern?

['wifi']['sta']['nameserver'] ist ja irgendsowatt jc-Parser-artiges... Die tatsächlichen Antworten vom Shelly kann man stattdessen im Browser sehen mit zum Beispiel: http://<Shelly-IP>/rpc/Shelly.ListMethods (ein passendes json-Plugin im Browser macht es schön)

Dort findet man dann einiges zu Wifi. Unter anderem: "Wifi.GetConfig" und "Wifi.GetStatus". Während in Wifi.GetConfig nur die konfigurierte SSID eingetragen ist, wenn der Shelly alles automatisch beziehen soll, sollte Wifi.GetStatus eigentlich alles liefern was altuell bezogen wurde, Dort steht aber tatsächlich nicht viel mehr als die erhaltene IP. Und DNS ist leer. Ich vermute aber, das ist nur ein Fehler bei der Rückgabe von Wifi.GetStatus, in dem Fall, dass alles via DHCP bezogen wurde. Eventuell kann man das aber mit "Wifi.SetConfig" passend setzen? Ich weiss es nicht und habe es auch nicht ausprobiert.

Es ist schon richtig: Entweder man macht ein Ticket bei Shelly auf oder man untersucht den Traffic des Shelly, wenn er zum Beispiel den ntp-Server befragt (nach einem Reboot des Shelly), denn der geht - wenn er nicht als lokal eingetragen ist - nur mit DNS-Server zu (zum Beispiel) pool.ntp.org oder time.cloudflare.com, die ohne Namensauflösung für den Shelly nicht erreichbar sind.

Meine Vermutung ist: Gateway und DNS-Server werden im Shelly bei DHCP richtig empfanden und sich gemerkt (nur "Wifi.GetStatus" zeigt es nicht)

Zitat von Schubbie

Kannst du Mal bitte zeigen, an welcher Stelle du die IP des Pi-Hole eingetragen hast und wie du es löst, dass die FritzBox interne Namen auflöst?

Entschuldigung, wenn ich mich einmische. Das ist superschnell und einfach erledigt:

1: Heinnetz > Netzwerk > Netzwerkeinstellungen > Erweiterte Netzwerkeinstellungen ändern > Ipv4 > Lokaler DNS-Server: hier den DNS-Server (pihole) eintragen.

2: Im Pihole wiederum die Fritzbox als DNS-Server eintragen.

3: In der Fritzbox kann man den DNS-Server entweder vom Internet-Provider beziehen oder andere eintragen (google oder oder )

Jetzt schickt die Fritzbox immer (bei Wlan und bei Lan Anfragen nach IPs duch lokale Systeme) pihole als DNS-Server mit. Pihole filtert dann Anfragen vor und fragt dann erst danach die Fritzbox zur Namensauflösung an, die natürlich auch alle lokalen Rechner kennt.

Nach meiner Erfahrung, ja, ohne Probleme. Ich habe keinerlei App installiert und verwende auch keine Cloud und handle alles über die Web-Gui der Shellys.

Zitat von AlfonsS

Fritzbox mit Firmware 8.20 zeigt dieses Verhalten. Shelly direkt über Browser erreichbar, aber nicht über Cloud ect.
Die Fritte zeigt im Mesh/Netzwerk eine andere IP an, als tatsächlich vergeben.

Sehr interessante Information. wo kann man mehr dazu erfahren (Link)?

Zitat von steffda

Dann rück' es doch grade. Dafür ist ein Forum doch da.

Wie geschrieben, an den Sätzen stimmt quasi nichts, deshalb:

Zitat von Jo_Be

. . . es ist schwer, das geradezurücken Aber sei's drum: wenn's klappt mit dem Internetzugang, dann ist ja "alles gut" . . .

Ich empfehle Wikipedia.org zu den Themen DNS-Server (https://de.wikipedia.org/wiki/Domain_Name_System#Nameserver) und DHCP (https://de.wikipedia.org/wiki/Dynamic_H…ration_Protocol) zu lesen, denn ein Forum für Shelly-Devices und Konfiguration ist sicher nicht dazu da, grundlegende Konzepte des Internets zu schulen.

Zitat von steffda

Nee, aber wenn man das Standardgateway als DNS einträgt, leitet dieses die Messages entsprechend weiter. Das dürften alle typischerweise im Homeoffice genutzten Router können.

Das hat den Vorteil, dass ich an einer Stelle in meinem Netzwerk bestimme, welchen DNS-Dienst ich nutzen will, nämlich den, der im Standardgateway eingestellt ist.

An diesen Sätzen stimmt quasi nichts Aber es ist schwer, das geradezurücken Aber sei's drum: wenn's klappt mit dem Internetzugang, dann ist ja "alles gut", wie man so sagt.

Zitat von thgoebel

ch erhalte von Zeit zu Zeit Rückläufer, um die Fehlerursachen zu eruieren und Produktverbesserungen anzuregen.

Da kann man sicher zweierlei verbessern: 1. Edelstahlgehäuse und 2. immer dann in dieser Variante versenden, wenn in der Bestellung angekreuzt ist: [ ] zwei linke Hände

Zitat von -JoSt-

Vielen Dank. Die Timer Funktion war der Schlüssel.

Bitte, gern geschehen. Für ein "Danke" unter meinem Beitrag fällt dir übrigens kein Zacken aus der Krone...

Timer: "Nach 5 Minuten automatisch wieder an"

Und es gibt natürlich eine Variante mit einem Script auf dem Shelly, das regelmässig abfragt, ob ein Rechner im LAN erreichbar ist (WLAN nicht ok), oder ein Rechner im Internet (DSL/Kabel/...-Zugang nicht ok) erreichbar ist und dann der Router ausschaltet und dann mit dem Timer wieder anschaltet.

Zitat von tvbshelly

Interessant, was es alles für Produkte gibt ... allein für NTP für Shelly natürlich "etwas teuer".

Unter Linux kann man (in jeder Distribution) mit "ntp" einen Zeitserver installieren und fein granuliert konfigurieren. Und dort bei Bedarf (z.B. längerfristiger Internetausfall) dann die Uhrzeit manuell einstellen. Einzige Voraussetzung ist natürlich sinnvollerweise, dass das entsprechende System ständig (24/7) läuft und im lokalen Netz aktiv ist (z.B. ein Raspi oder ähnlich). Auf Wunsch kann man dort dann natürlich auch ein Empfängermodul DCF77 (ca. unter 10 Euro) anschliessen.

Dann kann man das Internetkabel durchkneifen und einfach ohne Internet weitermachen

Was passiert, wenn nicht [OK] sondern stattdessen [Abbrechen] gedrückt wird? Nach meinem Verständnis würde das bedeuten, dass nichts verworfen und es noch einmal mit den gespeicherten Einstellungen versucht wird.

Das wäre aus meiner (Entwickler-)Sicht logisch (muss aber nicht der Shelly-Entwickler-Denke entsprechen):

[OK] bedeutet dann also etwas das: Ja, ok, stimmt, WLAN gibt es so nicht mehr und muss jetzt neu eingegeben werden. Also werden die nicht erfolgreichen Einstellungen gelöscht (was sehr gut ist).

[Abbrechen] bedeutet dann: Bitte zurück in die Warteschleife und versuch es noch einmal mit den Einstellungen, die gespeichert sind

Dieser Dialog erscheint scheinbar erst nach längeren Connect-Versuchen und soll zwei Dinge bewirken:

- den User auf ein (andauerndes) Problem aufmerksam machen

- verhindern, dass das WD es ewig weiter versucht, sich zu verbinden.

Ich nutze IOBroker nicht. Deshalb kann ich zur Kombination vom Ventil und IOBroker nichts sagen. Aber - wenn ich mich richtig erinnere - ist das Einstellen der Solltemperatur von extern hier schon besprochen und beschrieben worden.

Es geht zum Beispiel so:

curl -X POST -d '{"id":1,"method":"BluTrv.Call","params":{"id":200,"method":"TRV.SetTarget","params":{"id":0,"target_C":26.0}}}' http://IP-Gateway3/rpc

26.0 ist hier die Solltemperatur
"id":200 ist die ID des Ventils (die ID war, wenn ich mich richtig erinnere, Teil der Fragen an mich, nachdem ich dies hier veröffentlich hatte)
IP-Gateway3 hier die IP des Gateway3 eintragen

Zitat von Angel

Wieviele BLU TRV sind mit dem Gateway verbunden?

Eine gute Frage.

Zitat von Hurtz666

Es sind 4 Stück

Sind nicht nur 3 erlaubt/möglich?

Zitat von ankava

Was würde ich benötigen, um die Daten über InfluxDB oder Grafana auszulesen?
Ist da ein andere Lux Sensor sinnvoller?

Unter Linux: ... installieren von influxdb und grafana ggf noch mosquitto
und natürlich (auch mit HA) einen Empfänger für die Beacons, der die dann weiterleitet/verarbeitet.

HA ist was für Anfänger. Die eigene Verarbeitung via influxdb und Grafana ist natürlich viel anspruchsvoller und flexibler.

Wenn du die Werte schon - wie auch immer - empfängst, kann du sie einfach in einer Influxdb speichern (und auswerten und darstellen mit zb grafana).

Bei mosquitto (In /etc/mosquitto/mosquitto_conf) im zweiten Broker, der die Daten auch haben will:

connection beliebiger_(sprechender)_name
address IP_des_ersten_Brokers_der_die_Daten_vom_Shelly_erhaelt:1883
topic # in

Fertig! *)

*) Also drei Zeilen: connection NAME /address IP:PORT/topic XYZ in (# = alle Topics, in = nur Empfang)

Dieser zweite Broker meldet sich also dann bei ersten Broker an und sagt: Jip mir allet, was du bekommst, und der erste Broker macht dann - freundlicherweise - worum er gebeten wurde....

Das kamm man bei Smarthome-Systemen garantiert auch in irgendeiner Conf (ggf. händisch) eintragen....

Nennt sich "Bridge" siehe ua: https://mosquitto.org/man/mosquitto-conf-5.html

Ich hänge mich einmal hier mit hinein:

Ist jemandem ein Script bekannt, dass eine Email schicken kann? Ohne Cloud.

Zitat von Schwedenpeter

... Schwerkraft... Diese um 90 Grad zu kippen ist nicht einfach

Wieso, letztens hat doch das irgendwer mal hingekriegt. Und ja, die Nebenwirkungen waren übel... *)

*) Ach nee, der hatte nur aus Versehen ein Fenster um 90 Grad verdreht eingebaut...