Der Motor muss komplett in die Welle eingescho-ben werden, damit die Endabschal-tung arbeiten kann (Laufringadapter am Motorkopf )"
Exakt das ist das Problem, wenn der Motor nicht vollständig in der Welle montiert wurde schaltet er selbständig ab..
Habe ihn nur mal so angeschlossen, da ich ihn noch übrig hatte um zu schauen ob er funktioniert.
das geht (ganz sicher) nicht, bin vor Jahren in die gleiche Falle getappt.
was sagt denn das Log der FritzBox?
ab 1.0.8 sendet der Motion via Unicast (was ich wesentlich sinnvoller finde, weil es geroutet wird)..
dazu muss im Shelly-Motion unter Coiot die IP-Adresse des Coap-Receivers eingetragen werden.
Ob der ioBroker-Adapter damit zurecht kommt oder ggf. erst ein Update benötigt kann ich nicht sagen.
die kannst du für deine Variante vermutlich ignorieren
hier mal die Übersetzung der Coap-Daten
DeviceType: SHMOS-01 - DeviceID: 60A4239A66DA - Path: [cit s] - Payload:
{"G":[
[0,6107,0],
[0,3119,1614505914],
[0,3120,1],[0,6110,0],
[0,3106,1584],
[0,3111,70],
[0,9103,18]
]}{"blk":[{"I":1,"D":"sensor_0"},{"I":2,"D":"device"}],
"sen":[
{"I":6107,"T":"A","D":"motion","R":["0/1","-1"],"L":1},
{"I":3119,"T":"S","D":"timestamp","U":"s","R":["U32","-1"],"L":1},
{"I":3120,"T":"A","D":"motionActive","R":["0/1","-1"],"L":1},
{"I":6110,"T":"A","D":"vibration","R":["0/1","-1"],"L":1},
{"I":3106,"T":"L","D":"luminosity","R":["U32","-1"],"L":1},
{"I":3111,"T":"B","D":"battery","R":["0/100","-1"],"L":2},
{"I":9103,"T":"EVC","D":"cfgChanged","R":"U16","L":2}
]}Er bekommt es nicht mit da die dumme Sau nur schlafen will
nanana 
und nein, da hast du was falsch interpretiert.. er schläft nicht so wie die ESP-basierten Geräte (kein DepSleep!) sondern geht in den LowPower-Modus und blockt/bremst eingehenden Datenverkehr um Strom zu sparen..
wie er das im Detail macht hab ich auch nicht ganz verstanden.. SiliconLabs filtert da das "Grundrauschen" (Multicast, Broadcast) im Netzwerk irgendwie raus..
Du könntest ja mal deine FritzBox-& AccessPoint-Einstellungen hier preisgeben eventuell findet sich da der Grund.. hab ja auch noch zwei Boxen und diverse AVM-Repeater hier rumfliegen und kann den Fehler eventuell nachstellen
Für mich nicht mehr nachvollziehbar warum er mich mal sieht und dann nicht mehr . Die beiden fliegen am Montag in den Elektroschrott.
Alternativ könnte man versuchen den Fehler einzugrenzen..
- Blind Time zu hoch?
- AP Konfig prüfen, gibt da diverse Sachen, die es beeinflussen wie z.B. Autokanal, FastRoaming, Minimum DataRate Control, BandSteering, AirtimeFairness...
Je nach AP-Hersteller lassen sich Sachen konfigurieren, die sich massiv auf das Verhalten auswirken können.
als "temporäre" Lösung für den Akku mach Abfragen an die API, dann aber nicht minütlich sondern alle X Stunden. wenn man es nicht übertreibt verkraftet es der Sensor ganz gut.
MQTT und Coap senden ihre regulären Status-Updates (ohne Motion oder Tamper-Alarm) aktuell 1x pro Stunde.
Motion/NoMotion wird ja explizit per Action (in Kombination mit LUX in Sinne von Dark, Twilight und Bright) angeboten.
Lux alleine wird schwierig, so oft wie sich hier bei mir die Helligkeit im Raum ändert müsste er ständig senden.
dann MQTT oder Coap, per Action werden sie m.W. zumindest Stand jetzt nicht übertragen.
Er reagiert ab und zu nicht auf Bewegung, kommt das davon weil er schläft
"Schlafen" tut er eigentlich so gut wie immer.
das kommt eher davon, dass er dann entweder die Bewegung nicht wahrnimmt (Einstellungen des Sensors testen) oder dein WLAN zwischendurch mal Probleme hat (Paketverluste) / den Motion per Roaming zwischen APs hin und her schiebt.
Hab den selbst ja als Vorserien-Gerät schon seit ca. 3 1/2 Monaten in Betrieb und kann da keinerlei Probleme feststellen.
Für "Beleuchtung" sind die beiden RGBW´s unbrauchbar .....
Das sehe ich anders.. habe vier Stück (GU10) davon in einer Deckenlampe in einem ca. 18qm großen Raum. Die reichen im Warmweiß-Modus vollkommen aus (Raum ist taghell) und mein Sohn ist damit sehr zufrieden...
Farbe (egal welche) ist nur als Effekt-Licht brauchbar, das ist aber bei anderen Herstellern (egal ob Zigbee oder WLAN) bisher bei jeder LED gewesen, die ich getestet hab.
Die E27 RGBW (im Weiß-Modus) und die Vintage tun sich meines Erachtens ebenfalls nichts von der Helligkeit.
Ich finde sie jedenfalls für den Preis mehr als gut.
Wichtig: den ShellyMotion auf keinen Fall per Ping oder über Abfragen der REST-API überwachen..
Der ist zwar (im Gegensatz zu H&T, Flood, DW2...) permanent mit dem WLAN verbunden, macht aber trotzdem sowas ähnliches wie einen DeepSleep (geht in den LowPowerModus) um Strom zu sparen.
Daher auch die miserablen Antwortzeiten beim Ping und die träge Weboberfläche, wenn man sie nach längerer Zeit das erste Mal wieder aufruft.
Für das Überwachen der Zustände (Motion oder Tamper) stehen wahlweise MQTT, COAP oder HTTP-Actions zur Verfügung. Alle 3 Varianten sind Stromsparend, weil der Sensor selbst aktiv wird (und zwar nur dann, wenn es notwendig ist)
HTTP-API und Ping kommen von außen und verhindern quasi, dass der Sensor sich "schlafen" legen kann >>> extreme Akkubelastung.
Drum nochmal die Frage hat schon jemand Sensorwerte per Action übertragen wie es Dimitar schon mal angedeutet hat.
welche Sensorwerte willst du denn per HTTP übertragen? geht es um Lux? weil für Motion und Tamper sind ja Actions hinterlegt..
Ich hab meinen jetzt eine Woche und der Akku steht bei 64%.
Blöde Frage aber überwachst du den per Ping oder fragst ständig Daten via REST-API ab?
Mein Akku ist nach 3 Monaten bei 71% und das Ding muss bei mir echt leiden, weit weg von realen Bedingungen..
Coap/CoIoT im Sensor ist aktiv? Der soltle eigentlich per Default angehakt sein (bei mir ist er grad absichtlich aus), mag aber sein dass es nachträglich noch geändert wurde..
wie stelle ich denn Bright ein? dark und twilight habe ich gefunden.
Bright ist wie @Olsche schon geschrieben hat jeder LUX-Wert oberhalb vom twilight.. Wie hoch der Lux maximal sein kann, kann ich leider auch nicht sagen.
wenn du je einen Shelly mit einem Motor verbindest und über einen gemeinsamen Schalter/Taster steuerst sollte das eigentlich problemlos klappen..
Wenn die Motoren neu sind: Endlagen hast du vor Einbau der Shellys direkt am Motor aber eingestellt?
Male bitte mal ein Schaubild wie sie angeschlossen sind und hänge es hier an.. daran kann man ggf. sehen, ob es eher an falscher Verkabelung oder an z.B. den Endlagen oder falschen Einstellungen liegen könnte.
Das ist man aber von Allterco Robotics gewohnt, bei neuen Produkten wird der Kunde als Produkttester missbraucht!
kann bei neuen Produkten durchaus mal passieren, wir QA Tester finden zwar viele Fehler aber eben auch nicht alle..
Der Motion zeigt kein Update an und unter https://api.shelly.cloud/files/firmware ist er mit keiner Version gelistet.
nimm statt api (Produktion) repo.shelly.cloud..
http://<shelly-ip>/ota?url=http://repo.shelly.cloud/firmware/SHMOS-01_build.gblNodeRed läuft, wie z.B. Telegram, text2command, javaskript (Blockly) etc. als im ioBroker installierter Adapter...
ok, das war mir so direkt nicht bewusst.. dachte immer NodeRed ist ein eigenständiges Stück Software und bringt einen eigenen Coap-Listener (so wie der Shelly-Adapter) mit..
Im Zweifelsfall den NodeRed-Adapter abschalten und gucken, ob das Problem dadurch behoben wird..
Aktuelle Firmware (1.0.6) ist aber drauf?
Ja - wie gesagt, als Instanz/Adapter im io-Broker auf dem Raspberry...
ich bin mir nicht sicher, ob sich die beiden Instanzen in die Quere kommen können..
Wenn der NodeRed und der ioBroker beide auf dem gleichen Rechner einen Coap-Listener aufmachen dann dürfte es u.U. Probleme geben weil der Port bereits in Benutzung ist..
