Bei mir wird seit heute Vormittag bei 2 meiner Shellies diese neue Firmware angeboten, ohne dass ich bisher hier etwas davon gelesen hätte.
Wird die erst noch angekündigt?
Bei mir wird seit heute Vormittag bei 2 meiner Shellies diese neue Firmware angeboten, ohne dass ich bisher hier etwas davon gelesen hätte.
Wird die erst noch angekündigt?
Ich will hier keinen Glaubenskrieg über App-Stores anzetteln, da ich in dieser Beziehung auch äußerst vorsichtig bin. F-Droid wird jedoch von vielen Fachzeitschriften als sichere Alternative zum Playstore gezählt.
PS. Auch das nur für eventuelle Nachbauer, denn Du hast Tasker ja schon gekauft und brauchst keine Alternative.
Ich verwende dafür 'Easer'. Die App gibt es bei F-Droid. Komplett umsonst und werbefrei.
Den von mir in Firmware 1.10.4 officially released #56 festgestellten DNS-Fehler habe ich jetzt in einem Testsystem mit einem neuen Shelly2.5 nachgestellt.
Es ist also schon länger so, dass beim WIFI Client Backup bei einer statischen Adresse der DNS-Server nicht richtig angesprochen wird.
Einstellungen Shelly:
"wifi_sta":
{"enabled":true,
"ssid":"Test1",
"ipv4_method":"static",
"ip":"172.16.51.2",
"gw":"172.16.51.1",
"mask":"255.255.255.0",
"dns":"172.16.51.1"},
"wifi_sta1":
{"enabled":true,
"ssid":"Test2",
"ipv4_method":"static",
"ip":"172.16.52.2",
"gw":"172.16.52.1",
"mask":"255.255.255.0",
"dns":"172.16.52.1"},
Alles anzeigen
Wenn ich jetzt im Test1 Netz bin, sehe ich im Firewall-Log, dass der Shelly DNS-Einträge auf der Adresse: 172.16.51.1 sucht. Schalte ich dann das Netz Test1 ab, verbindet sich der Shelly mit dem Netz Test2, er sucht aber die DNS-Einträge immer noch nach dem DNS-Server vom Netz Test1.
14:11:04 Default DROP UDP 172.16.51.2 : 53720 → 172.16.51.1 : 53
14:11:09 Default DROP UDP 172.16.51.2 : 53720 → 172.16.51.1 : 53
14:11:27 Default DROP UDP 172.16.51.2 : 53721 → 172.16.51.1 : 53
14:11:30 Default DROP UDP 172.16.51.2 : 53721 → 172.16.51.1 : 53
14:11:36 Default DROP UDP 172.16.51.2 : 53721 → 172.16.51.1 : 53
14:11:59 Default DROP UDP 172.16.51.2 : 53722 → 172.16.51.1 : 53
14:12:58 Default DROP UDP 172.16.52.2 : 53724 → 172.16.51.1 : 53
14:12:58 Default DROP UDP 172.16.52.2 : 53725 → 172.16.51.1 : 53
14:13:01 Default DROP UDP 172.16.52.2 : 53724 → 172.16.51.1 : 53
14:13:02 Default DROP UDP 172.16.52.2 : 53725 → 172.16.51.1 : 53
14:13:06 Default DROP UDP 172.16.52.2 : 53724 → 172.16.51.1 : 53
14:13:08 Default DROP UDP 172.16.52.2 : 53725 → 172.16.51.1 : 53
Alles anzeigen
Kann jemand von Euch den Fehler bestätigen oder ihn an Alterco melden. Ich habe kein Facebook-Konto.
Seit der Umstellung auf 1.10.4 habe ich das Problem, dass die Umschaltung auf das Wifi-Client-Backup-System nicht richig funktioniert.
Die Settings sind mit statischen Adressen richtig gesetzt:
"wifi_sta":{"enabled":true,
"ssid":"7412iot",
"ipv4_method":"static",
"ip":"172.16.10.33",
"gw":"172.16.10.1",
"mask":"255.255.255.0",
"dns":"172.16.10.1"},
"wifi_sta1":{"enabled":true,
"ssid":"iot",
"ipv4_method":"static",
"ip":"172.16.5.33",
"gw":"172.16.5.1",
"mask":"255.255.255.0",
"dns":"172.16.5.1"},
"ap_roaming":{"enabled":false,"threshold":-70}
Alles anzeigen
aber die Verbindung zu MQTT funktioniert nicht und auch der Zugriff auf das Internet für die Uhrzeit usw.
Mein Firewall-Log bringt dafür laufend verworfene Pakete von Zweitnetz in das Primärnetz:
12:08:29 Default DROP Virtual Extensible LAN 172.16.5.39:4096 → 172.16.10.1:53
oder ausführlich
2021:05:09-12:11:36 fw ulogd[5729]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="wlan3" outitf="eth1" mark="0x35b7" app="1463" srcmac="98:f4:ab:f4:09:12" dstmac="00:1a:8c:0a:85:03" srcip="172.16.5.33" dstip="172.16.10.1" proto="17" length="57" tos="0x00" prec="0x00" ttl="127" srcport="4096" dstport="53"
Die Source-IP von wfi-sta1 versucht auf die Destination-IP der Gateway von wfi-sta zuzugreifen. Das kann nicht funktionieren.
In der Vergangenheit hat die Umstellung zwischen den Netzen gut funktioniert. Bei welchem der letzten updates es genau nicht mehr ging, kann ich nicht sagen, da der netzwechsel nicht so häufig ist.
Edit: Nachdem ich bei einem der betroffenen Shellies den FQDN des MQTT-Servers und des NTP-Servers durch IP- Adressen ersetzt habe, geht es. D.h. der DNS-Eintrag von STA1 wird nicht richtig gespeichert oder verwendet.
Meine Version ist 1.10.6
Auch mit sudo kam nichts anderes. Ich habe das Terminal mit su geöffnet und arbeite in dem Fall als root.
Das Netbook hat nur 32bit. Daher geht kein neueres Ubuntu.
Ich hatte gestern leider nicht viel Zeit um mich mit dem Script zu beschäftigen, konnte dann aber doch so langsam durchsteigen und es für mich anpassen.
Wie beschrieben habe ich die Argumente getauscht und kann somit auch ohne statische IP arbeiten.
Warum es bei mir anders ist, kann ich nicht sagen, aber ich musste die zwei Zeilen mit 'awk' um eine Zahl senken. "
current_ssid="$(nmcli device "$wlan_device" list | grep '^\*' | awk '{print $3}')"
auf
current_ssid="$(nmcli device "$wlan_device" list | grep '^\*' | awk '{print $2}')"
usw.
(Ich arbeite auf einem alten Netbook mit Lununtu 18.4.)
Um die starke Netzbelastung zu verhindern, habe ich auch noch COIOT abgeschaltet. (Tip hier aus dem Forum)
settings_coiot_enabled='0'
# disable Coiot
if [ "$settings_coiot_enabled" == '0' ]; then
url="http://$shelly_init_ip/settings?coiot_enable=$settings_coiot_enabled"
echo "$url"
curl -s "$url" > /dev/null
fi
Die weiteren Anpassungen bei mir betreffen nur Rolladensteuerungen, da ich hier gerade eine größere Zahl einzurichten habe.
Nochmals vielen Dank für die konstuktive Hilfe.
Da hast Du Dir ein geiles Script ausgedacht. Ich werde es gerne probieren.
Ein Verständnisproblem habe ich noch:
Wenn ich dhcp verwenden will und daher das erste Argument wegfällt, wie kann dann der Name vergeben werden, da er ja dann das erste Argument ist?
Bei mir steht in Zeile 21 enabled=true. Das ist doch dasselbe wie enabled=1?
Danke. Jetzt geht's.
Warum es aber mit dem Einzeiler in Zeile 20 nicht geht, wo alles richtig geschrieben ist, ist mir noch unklar.
Da ich das Alles als Test auf einem Raspi probiere, muss ich nichts unkennlich machen. Ist bisher quick and dirty.
#!/bin/sh
#
# Diese Skript erkennt neue Shellies und bereitet sie soweit vor, dass sie im Hauptnetz erscheinen-
WLAN=`iwlist wlp2s0 scan | grep shellysw | sed 's/ESSID:"//' | sed 's/"//'`
echo "Folgendes Shelly-WLAN wurde ermittelt: $WLAN"
nmcli device wifi connect $WLAN
echo "Rechner wurde mit $WLAN verbunden."
init_ip='192.168.33.1'
ssid='shelly-ip'
key='shelly4iot'
ipv4_method='dhcp'
url="http://$init_ip/settings/sta?&enabled=1&ssid=$ssid&key=$key&ipv4_method=$ipv4_method"
curl "$url"
#curl http://192.168.33.1/settings?mode=roller
#curl http://192.168.33.1/settings/sta?ssid=shelly-pi&key=shelly4iot&ipv4_method=dhcp
#curl http://192.168.33.1/settings/sta?enabled=true
echo "Shelly wurde für WLAN 'shelly-pi' eingerichtet."
Alles anzeigen
Der key hat keine Sonderzeichen, nur Buchstaben und eine Zahl.
Auch das obige Script funktioniert bei mir nicht. Es verhält sich genauso wie bei mir mit einer Zeile.
Der key wird ja auch nicht in der Antwort vom Shelly angezeigt. Das ist aber immer so, auch bei einer reinen Abfrage.
Ich wollte mir ein Script schreiben, das mir neue Shellies in das heimische WLAN bringt.
Bisher habe ich geschafft, dass das Script erkennt, wenn ein neuer Shelly seinen AP anbietet, der Rechner sich dann an diesem AP anmeldet und einige Parameter setzt.
Die Zeile 'curl http://192.168.33.1/settings/sta?ssid=abcd&ipv4_method=dhcp' wird übergeben und angezeigt. Bei der Übergabe des WLAN-Schlüssels scheitere ich. Ob ich es in den obigen Befehl integriere oder eine eigene Zeile schreibe ('curl http://192.168.33.1/settings/sta?key=xxxxxx') wird es nicht oder falsch übergeben und wenn ich dann aktiviere bin ich im Nirwana. Der AP ist abgeschaltet und im Heimnetz meldet er sich nicht an. Dann hilft nur Reset.
Hat von euch schon jemand die Übergabe des key geschafft?
Das habe ich versucht, aber das ging nicht.
Dann habe ich gewartet, bis der ShellyHT wieder oinline war und manuel den set <device> x_update Befehl abgesetzt. Das ging auch nicht.
Bei mir hat es nur geklappt, wenn ich während der online-Zeit auf die Web-Oberfläche gegangen bin und dort das Update angestossen habe. Muss halt schnell gehen.
Ich weis nicht, ob es ein genereller Fehler ist, aber über MQTT habe ich es nicht geschafft.
Ich suche schon länger, wie man ShellyHT oder andere batteriebetriebene Shellies aus FHEM heraus updaten kann.
Bisher habe ich nicht gefunden, wie man den MQTT2-Server dazu bewegen kann den update-Befehl über QOS 1 oder QOS 2 so lange vorzuhalten, dass der Shelly beim nächsten Anmelden das publish-command auch erhält.
Wie habt ihr das gelöst? Was habe ich bisher übersehen?
cu
Walter
Beim Abkoppeln ist wohl was schief gelaufen. Ich habe mit dem Thread nichts zu tun.
Warum gibst Du nicht fhem zur Auswahl? Ich glaube, das nutzen einige hier.
Vielen Dank für Eure Hinweise. Das war das, was ich gesucht habe.
Durch die vorgehenden Posts war ich verwirrt und suchte bei deltaReading.
Wofür deltaReading aber dann zu gebrauchen ist, weiß ich aber immer noch nicht.
Ich hole den Thread noch einmal hervor, da ich ein Verständnisproblem habe.
Wie von Kai vorgeschlagen, ist das statistik-Modul vorhanden und mit deltaReadings baut sich der statRoller_0_energy Wert langsam auf.
Heute habe ich den Shelly neu gestartet und damit ist der Wert für roller_0_energy wieder bei null.
Da es schon einen Wert für roller_0_energy gab und jetzt über delta der gesammelte Wert wieder abgezogen wurde sind die Werte alle in den negativen Bereich gesprungen.
Ich hatte es so verstanden, dass dies die Lösung für das Problem des Vergessens der Werte beim Neustart sein sollte.
Wenn Du ein übergeordnetes System verwendest (ich verwende z.B. fhem) kannst Du mit der Intertechno Fernbedienung oder Schalter auch die Shelly direkt ansteuern.
Ich steuere einige meiner Rolläden mit der Intertechno-Fernbedienung, die auf anderen Kanälen Licht steuert.