Beiträge von waki

    Offset habe ich bei beiden nicht eingegeben.

    Den absolut richtigen Temperaturwert erwarte ich auch nicht.

    Ich wundere mich nur, dass der eine nur z.B. 5.5, 6.0, 6.5, 7.0 anzeigt und der andere 5.5, 5.6, 5.7, 5.8, 5.9 usw.

    Ich habe an ein Add-on von meinem Shelly1 zwei Thermofühler vomTyp DS18B20 angeschlossen. Der Fühler, der als Temperature 2 angezeigt wird, misst auf .1 Grad genau und der auf Temperature 1 nur auf .5 Grad.

    Kann man das irgendwo einstellen oder können die Fühler zwar äußerlich gleich aber intern unterschiedlich sein?

    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:

    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.

    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:

    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:

    Code
    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.

    Und so schaut es bei mir aus:

    Code
    nmcli device wifi list
    IN-USE  SSID         MODE   CHAN  RATE       SIGNAL  BARS  SECURITY 
    *       AstaroGuest  Infra  8     65 Mbit/s  58      ▂▄▆_  WPA2     

    Übrigens muss ich auch vor der Abfrage immer einen Rescan machen, da der alte Hobel mir sonst nur den aktuellen Zugang anzeigt.

    Code
    nmcli device "$wlan_device" rescan

    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. "

    Code
    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)

    Code
    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?

    Da ich das Alles als Test auf einem Raspi probiere, muss ich nichts unkennlich machen. Ist bisher quick and dirty.

    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

    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. :?: