Test Adapter Shelly v4.0.6 (latest)
-
Bei mir läuft FW 1.10.0 und nun 1.10.1 mit unicast im Fritz Mesh mit Adapter v4.7b1 problemlos.
Es scheint auch durchaus weniger Wifi Traffic/Konflikte zu geben. Zumindest reagieren alle Tasmota Geräte mit Emulation sofort bei Steuerung über Alexa. Monatelang habe ich immer als erste Antwort "Gerät antwortet nicht, bitte überprüfen sie ihr Netzwerk" erhalten. Beim zweiten Sprachbefehl hat es dann immer funktioniert. Seit ich die Shellys auf unicast umgestellt habe, reagieren alle Tasmota Geräte beim ersten Befehl. Ob die Shellys da zu viel Alarm im Netz gemacht haben - ich weiß es nicht... -
@dos1973 sagte in Test Adapter Shelly v4.0.6 (latest):
ich habe hier noch etwas mit dem motionsensor. ist das bekannt?
shelly.0 2021-03-22 18:34:02.090 info (2453) Destroy 192.168.30.91 (shellymotionsensor / shellymotionsensor-60A423992C2A / undefined#60A423992C2A#1) shelly.0 2021-03-22 18:34:02.090 info (2453) Close Client: 192.168.30.91 (shellymotionsensor / shellymotionsensor-60A423992C2A / undefined#60A423992C2A#1) (false) shelly.0 2021-03-22 18:34:01.782 error (2453) Shelly Device unknown, configuration for Shelly device 192.168.30.91 (shellymotionsensor / shellymotionsensor-60A423992C2A / undefined#60A423992C2A#1) for MQTT does not exist!shelly Motion Sensor:
Current version: 20210226-072307/v1.1.0@f31e1d2bShelly Adapter:
4.0.7-beta-3verbunden via MQQT
hat das noch jemand, bzw. kann mir evtl. ein Tipp geben?
-
@dos1973 , kannst Du bitte einmal http://ip_of_shelly_motion/settings wie z.B. http://192.168.25.160/settings aufrufen. Den Output hätte ich gerne. Ich bin mir nicht sicher ob es vielleicht unterschiedliche Versionen vom Motion gibt und es deshalb nicht funktioniert.
Ich habe auch die Firmware 4.0.7-beta-3 im Einsatz mit MQTT mit dem Shelly Motion und alles funktioniert wunderbar. Wenn das nicht hilft, dann führe unter dem Menüpunkt ein Upload für den Shelly Adapter durch. Dafür auf den Tab Adapter gehen und beim Shelly auf die 3 senkrechten Punkte klicken. Hier findest Du Upload (Icon Pfeil nach oben). Danach die Shelly Instanz neu starten.
-
{ "device": {"type": "SHMOS-01","mac": "60A423992C2A","hostname": "shellymotionsensor-60A423992C2A","num_outputs": 0},"wifi_ap": {"enabled": false,"ssid": "shellymotionsensor-60A423992C2A"},"wifi_sta": {"enabled":true,"ssid":"D_IoT_WZ2G","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"mqtt": {"enable":false,"server":"192.168.10.6:1883","user":"d","id":"shellymotionsensor-60A423992C2A","clean_session":true,"max_qos":0,"retain":false,"update_period":3600},"sntp": {"server": "time.google.com","enabled": true},"login": {"enabled": false,"unprotected": false,"username": "admin","auth_type": "basic","default_username": "admin"},"pin_code": "x(!WR4","name": null,"fw": "20210226-072307/v1.1.0@f31e1d2b","discoverable": true,"build_info": {"build_id": "20210226-072307/v1.1.0@f31e1d2b","build_timestamp": "2021-02-26T07:23:07Z","build_version": "2021022607"},"cloud": {"enabled": false},"coiot": {"enabled": false,"update_period":3600,"peer":"192.168.10.6:5683"},"timezone": "Europe/Berlin","lat": 51.661230,"lng": 6.964830,"tzautodetect": true,"tz_utc_offset": 7200,"tz_dst": false,"tz_dst_auto": true,"time": "10:52","sleep_time": 0,"motion": {"sensitivity": 30,"blind_time_minutes": 3,"pulse_count": 1,"operating_mode": 0,"enabled": true},"tamper_sensitivity": 2,"led_status_disable": false,"dark_threshold": 100,"twilight_threshold": 500,"schedule": false,"schedule_rules": [],"hwinfo": {"hw_revision": "dev-prototype","batch_id": 0},"sleep_mode":{"period":60,"unit":"m"} }upload hatte ich schon gemacht, hat nicht geholfen
-
@Stuebi
ich stelle selbst gerade fest, wieso hat der bei ip, dns, etc keine werte? -
@dos1973 , aber nach deiner config, ist MQTT disabled. Und der Punkt mit IP, DNS ist irrelevant für Dein Problem.
-
ja, sorry, hatte es deaktiviert wegen der ganzen logs... hier nochmals ein
{ "device": {"type": "SHMOS-01","mac": "60A423992C2A","hostname": "shellymotionsensor-60A423992C2A","num_outputs": 0},"wifi_ap": {"enabled": false,"ssid": "shellymotionsensor-60A423992C2A"},"wifi_sta": {"enabled":true,"ssid":"D_IoT_WZ2G","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"mqtt": {"enable":true,"server":"192.168.10.6:1883","user":"d","id":"shellymotionsensor-60A423992C2A","clean_session":true,"max_qos":0,"retain":false,"update_period":3600},"sntp": {"server": "time.google.com","enabled": true},"login": {"enabled": false,"unprotected": false,"username": "admin","auth_type": "basic","default_username": "admin"},"pin_code": "x(!WR4","name": null,"fw": "20210226-072307/v1.1.0@f31e1d2b","discoverable": true,"build_info": {"build_id": "20210226-072307/v1.1.0@f31e1d2b","build_timestamp": "2021-02-26T07:23:07Z","build_version": "2021022607"},"cloud": {"enabled": false},"coiot": {"enabled": false,"update_period":3600,"peer":"192.168.10.6:5683"},"timezone": "Europe/Berlin","lat": 51.661230,"lng": 6.964830,"tzautodetect": true,"tz_utc_offset": 7200,"tz_dst": false,"tz_dst_auto": true,"time": "10:59","sleep_time": 0,"motion": {"sensitivity": 30,"blind_time_minutes": 3,"pulse_count": 1,"operating_mode": 0,"enabled": true},"tamper_sensitivity": 2,"led_status_disable": false,"dark_threshold": 100,"twilight_threshold": 500,"schedule": false,"schedule_rules": [],"hwinfo": {"hw_revision": "dev-prototype","batch_id": 0},"sleep_mode":{"period":60,"unit":"m"} } -
@dos1973 , leider kann ich mir den Fehler nicht erklären. Ich habe den Shelly Motion mit MQTT ohne Probleme testweise im Einsatz. Bei mir funktioniert dieser wunderbar auch wenn ich diesen niemals produktiv einsetzen würde.
-
hmm, das ist jetzt weniger gut.
hard reset hatte auch nichts gebracht. Würde mich interessieren ob ich ein Montags Modell erwischt habe? -
@dos1973
ich meine ich hatte das schon gemacht, ja sogar sicher.... aber aus Verzweiflung habe ich eben einfach nochmals den Adapter via "Katze" installiert und ein Upload gemacht.jetzt ist der Shelly in der Version 4.07 (ohne Beta) installiert und es geht.
ist ggf. in der Beta3 doch noch ein Bug versteckt?{ "device": {"type": "SHMOS-01","mac": "60A423992C2A","hostname": "shellymotionsensor-60A423992C2A","num_outputs": 0},"wifi_ap": {"enabled": false,"ssid": "shellymotionsensor-60A423992C2A"},"wifi_sta": {"enabled":true,"ssid":"D_IoT_WZ2G","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"mqtt": {"enable":true,"server":"192.168.10.6:1883","user":"d","id":"shellymotionsensor-60A423992C2A","clean_session":true,"max_qos":0,"retain":false,"update_period":3600},"sntp": {"server": "time.google.com","enabled": true},"login": {"enabled": false,"unprotected": false,"username": "admin","auth_type": "basic","default_username": "admin"},"pin_code": "G)mxg9","name": null,"fw": "20210226-072307/v1.1.0@f31e1d2b","discoverable": true,"build_info": {"build_id": "20210226-072307/v1.1.0@f31e1d2b","build_timestamp": "2021-02-26T07:23:07Z","build_version": "2021022607"},"cloud": {"enabled": false},"coiot": {"enabled": true,"update_period":3600,"peer":"192.168.10.6:5683"},"timezone": "Europe/Berlin","lat": 51.661230,"lng": 6.964830,"tzautodetect": true,"tz_utc_offset": 7200,"tz_dst": false,"tz_dst_auto": true,"time": "11:21","sleep_time": 0,"motion": {"sensitivity": 50,"blind_time_minutes": 5,"pulse_count": 1,"operating_mode": 0,"enabled": true},"tamper_sensitivity": 2,"led_status_disable": false,"dark_threshold": 100,"twilight_threshold": 500,"schedule": false,"schedule_rules": [],"hwinfo": {"hw_revision": "dev-prototype","batch_id": 0},"sleep_mode":{"period":60,"unit":"m"} } -
@dos1973 , eigentlich nicht, da die 4.0.7-beta-3 identisch mit der Version 4.0.7 ist. Wahrscheinlich war die Version 4.0.7-beta-3 nicht richtig installiert. Aber jetzt ist ja zum Glück alles bestens
-
Ich vermisse den weggefallenen Online-Status auch. Verstehe nicht, warum dieser für alle Shellys wegfallen muss oder warum man dies nicht konfigurierbar machen kann. Vielleicht findet sich ja noch eine Möglichkeit.
Ich habe einen Shelly mit sehr schlechter WLAN-Verbindung, wo die Auswertung des Online-Status die Probleme, die durch die schlechte Verbindung auftreten, gelöst wurden. Ich werde jetzt mal versuchen, ob ich stattdessen den Ping-Adapter verwenden kann, um den Wegfall zu kompensieren.Grüße Daniel
-
@iodaniel
komme gerade ins Forum um genau danach zu suchen. Habe in meinen Logiken hinterlegt, dass diverse Aktionen nur ausgeführt werden, wenn auch diverse Shellys Online sind. Somit waren diverse Aktionen derzeit nicht mehr ausführbar und die Fehlersuche hat den fehlenden DP für die Shellys ergeben 
Bin auch nicht begeistert dafür jetzt einen anderen Adapter laufen zu lassen, aber ist mir lieber als endlos Befehle ins Nirvana zu schicken die nie bei einem Shelly ankommen. -
@ralf-0 @ioDaniel
Sicherlich kann der online Status helfen, aber sinnvoller ist es bei verbindungsproblemen zu schauen ob der Befehl umgesetzt wurde und diesen ggf nochmal zu wiederholen. Theoretisch kann der Adapter ja auch online anzeigen und der shelly kurz davor die Verbindung verloren haben. Bis sich der Status ändert, wird immer etwas Zeit schon der shelly offline gewesen sein.
Noch sinnvoller wäre es aber an der wlan Infrastruktur zu arbeiten und somit verbindungsabbrüche zu vermeiden. Was bringt es einem wenn man jetzt unbedingt was schalten will, weiß das es nicht geht weil nicht online, aber man trotzdem nicht schalten kann?
Ständige pings und abfragen machen dabei das ganze System auch nicht stabiler. Sinnvoller ist auch hier nur traffic im wlan auf das nötigste zu beschränken damit genug Ressourcen immer zu Verfügung stehen. -
@e-s sagte in Test Adapter Shelly v4.0.6 (latest):
Noch sinnvoller wäre es aber an der wlan Infrastruktur zu arbeiten und somit verbindungsabbrüche zu vermeiden. Was bringt es einem wenn man jetzt unbedingt was schalten will, weiß das es nicht geht weil nicht online, aber man trotzdem nicht schalten kann?
Es gibt Anwendungsfälle, bei denen es durchaus nützlich sein könnte, dass man z.B. eine Benachrichtigung erhält, dass Gerät X nicht erreichbar ist. Ich müsste da jedebfalls jetzt einen Würgaround basteln, den Adapter downgraden, oder auf einen anderen wechseln...
Ständige pings und abfragen machen dabei das ganze System auch nicht stabiler. Sinnvoller ist auch hier nur traffic im wlan auf das
Jo, klar - muss man sich nur mal bei einem „durchschnittlichen“ iobroker das Events-Gewitter anschauen
- da macht ein Ping alle paar Sekunden genau keinen Unterschied (natürlich nur bei Geräten ohne Batterie)nötigste zu beschränken damit genug Ressourcen immer zu Verfügung stehen.
-
@jleg
Ich habe ca 45 shellys, 2-3 haben mich zwischendurch auch immer mal wieder geärgert.
Ständig waren im log reconnects zu sehen. Habe dann immer weiternmein wlan verbessert, seit dem habe ich im log nur noch äußerst selten ein shelly Eintrag.
Deswegen brauch ich mir wegen online Status keine Gedanken mehr machen.
Deswegen eben versuch lieber den Fehler selbst zu beseitigen anstatt dich über die Überwachung zu kümmern. -
Sicher auch kein Thema was hier in den Adaptertestbeitrag gehört. War mir nur nicht 100% klar ob das Fehlen dieses DPs vom Adapter oder von der FW des Shelly kommt.
Eure Argumente, dass ein DP kein stabiles Wifi ersetzt oder der Traffic durch zusätzliche Pings im Prinzip total vernachlässigbar ist stimme ich voll zu.
Ich betrachte das auch aus anderen Blickrichtungen. Wenn der DP vorhanden ist brauche ich keinen Ping Adapter und somit ist meine Gesamtlösung "simpler" (Ein Adapter braucht auch RAM auf dem RPI). Vom Prinzip finde ich das gut, da einfacher zu Überblicken und weniger Zeuch kann auch weniger kaputt gehen.
Im Normalbetrieb ist das auch alles kein Thema. Ich hatte nur Situationen wo das System durch einen Reboot eines ESPs in einen ungewollten Zustand versetzt wurde. Danach schaukelten sich die Logiken und Logs/Alarme etc. kräftig "hoch", das nacher eine Art Alarm&Event Verfolgung sehr schwierig wurde. Baut man hier gewisse Verriegelungen ein, hilft das extrem den Log und das System brauchbar und in vorhersagbaren Zuständen zu halten. Ich habe da kein gutes Bauchgefühl mit etlichen Logiken und den Shellys zu arbeiten und dann treten wie in der jüngsten Vergangenheit instabile Zuszände im Wifi durch die FW auf. Dadurch gehen 35 Shellys Offline und ich denke mir, dass der IObroker dann anfängt ganz schön viel "Müll" zu produzieren wie Wifi Traffic, im Log und bzgl. eigener Auslastung. Wenn sich das etwas mit vernünftigen Aufwand verhindern lässt bin ich dabei
-
@ralf-0 said in Test Adapter Shelly v4.0.6 (latest):
War mir nur nicht 100% klar ob das Fehlen dieses DPs vom Adapter oder von der FW des Shelly kommt.
wenn du dir IP/staus, IP/settings anschaust, gibts online nicht, also ist es von der FW nicht vorgesehn.
du kannst dir auch die API Reference belinsen. -
Mir werden von meinen Shelly 1PM keine Stromwerte und Temperaturen angezeigt.
Folgendes steht im LOG:
2021-05-07 13:04:48.204 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.Relay0.Switch" has no existing object, this might lead to an error in future versions 2021-05-07 13:04:48.205 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.Relay0.longpush" has no existing object, this might lead to an error in future versions 2021-05-07 13:04:48.206 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.Relay0.Input" has no existing object, this might lead to an error in future versions 2021-05-07 13:04:48.207 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.Relay0.Power" has no existing object, this might lead to an error in future versions 2021-05-07 13:04:48.207 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.Relay0.Energy" has no existing object, this might lead to an error in future versions 2021-05-07 13:04:48.216 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.overtemperature" has no existing object, this might lead to an error in future versions 2021-05-07 13:04:48.216 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.overpower" has no existing object, this might lead to an error in future versions 2021-05-07 13:04:48.232 - error: shelly.0 (2145) Error in function httpIoBrokerState for state SHSW-PM#84CCA8AFA776#1.Relay0.ChannelName and request{"url":"http://192.168.2.117/settings/relay/0","timeout":5000} for 192.168.2.117 (shelly1pm / shelly1pm-84CCA8AFA776 / SHSW-PM#84CCA8AFA776#1) (SyntaxError: Unexpected token B in JSON at position 0) 2021-05-07 13:04:48.429 - warn: shelly.0 (2145) State "shelly.0.SHSW-PM#84CCA8AFA776#1.name" has no existing object, this might lead to an error in future versions 2021-05-07 13:05:48.529 - error: shelly.0 (2145) Error in function httpIoBrokerState for state SHSW-PM#84CCA8AFA776#1.Relay0.ChannelName and request{"url":"http://192.168.2.117/settings/relay/0","timeout":5000} for 192.168.2.117 (shelly1pm / shelly1pm-84CCA8AFA776 / SHSW-PM#84CCA8AFA776#1) (SyntaxError: Unexpected token B in JSON at position 0)Shelly Firmware bei beiden gleich:
The current Firmware version of your Shelly device is 20191219-114622/1047-long-id-for-shelly-devices@d05667c7Kann mir jemand helfen ?
-
@marcuskl sagte in Test Adapter Shelly v4.0.6 (latest):
20191219
nochmal, das ist die auslieferungs FW. 19.12.2019
