VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Ich interpretiere in der original Doku das "-t" am veränderlichen Widerstandssymbol als negativen Temperaturkoeffizient. Ich kenne dafür zwei gegenläufige Pfeile.
Wenn meine Interpretation stimmt, sieht Allterco tatsächlich einen NTC vor.
Bestätigung aus der Doku:
Ist bekannt, wie belastbar Vref out ist oder deren innerer (differentieller) Widerstand?
Ich bin heute wohl etwas zu nervös. Ich fand soeben dass dieser Ausgang max. mit 1mA belastbar sei.
Sorry
Hmm, einen im AddOn integrierten Analog-Multiplexer wünsche ich mir noch. 
Nachgereicht:
Entschuldigung, das war etwas unsinnig, da ein ESP32 bereits über mehrere analoge Eingänge verfügt.
Also bräuchte es nur ein paar zusätzliche Klemmen.
An anderer Stelle in diesem Forum sah ich, dass zum Plus Addon der Anschluss eines NTC Widerstandes zwischen Ground und Analog In vorgesehen ist, was auch hier zu sehen ist.
Es wird elektronisch verständlich, wenn, wie dargestellt, der NTC mit einem R1 (Wert unbekannt) in Reihe an einer Referenzspannung betrieben wird.
Dann wünsche ich schlicht frohes Experimentieren.
Ungetestet aber ziemlich wahrscheinlich funktionstüchtig:
In irgendeinem Frontend (Bedienungsoberfläche) einen Schalter für Abwesenheit oder "Urlaub" bereitstellen.
Wird der virtuelle Schalter auf ein/aktiv gestellt, zwei (oder mehr?) Nachrichten per HTTP oder MQTT oder ??? an alle betreffenden Shellies senden, die
Wird der Schalter auf aus/inaktiv gestellt, per Nachricht das Scheduling auf den betreffenden Shellies aktivieren.
Ich täte es mit Node RED - in Homematic afaik RedMatic - und MQTT lösen, per HTTP dürfte es aber auch gelingen, falls kein MQTT zur Verfügung steht.
Btw. ähnliches habe ich per Node RED für meine lokalen Heizungssteuerungen so gelöst. Mein System ist gemischt mit TRVs und Shelly 1 + Addon realisiert. Allerdings nutze ich das Scheduling nur in den TRVs.
Nachtrag:
Die Urlaubswerte lassen sich in einem Konfigurationsknoten leicht verwalten und von dort holen, sowohl global als auch Flow bezogen. Optional können solche Daten persistent gespeichert (Dateisystem) und beim starten von Node RED in die Konfiguration geladen werden.
Ok, das könnte nicht schaden. Ich frage mich aber auch, warum jemand das von dir Erwähnte einfach mal so versucht, offenbar ohne Kenntnisse in Elektrotechnik/Elektronik. Aber gut, er hat ja Hinweise dazu erhalten. 
Meine Frage wäre ...
Plötzlich wird bei beiden das Addon nicht mehr erkannt.
Wie stellst du dieses Nichterkennen fest, soll heißen was verwendest du dafür?
Btw ich verstehe die Beliebtheit der App-Nutzung außerhalb er Cloud nicht.
Ich habe soeben auf 5 Plug S ein Firmware Update durchführen lassen - keinerlei Probleme, Konfigurationen und Funktionen blieben erhalten.
Vielleicht gab es bei dir während des Updates eine Störung im Stromnetz.
Btw ich verwende die App nie für lokale Zugriffe. Dafür sind imho die WebUI am besten geeignet.
WebUI auf meinem Smartphone, Shelly Plus 2PM mit Firmware 0.12.0:
... oder eine Messbrücke
Ich habe den Plus Add-On auch (noch) nicht.
@66er Ich kannte den RuuviTag bisher nicht. Interessant daran scheint mir dessen Witterungsfestigkeit und die Reichhaltigkeit an Sensoren. So würde ich den RuuviTag vielleicht anstatt eines Plus Addon im Außenbereich einsetzen.
Neugierig - darf ich fragen, wie und/oder wo du den RuuviTag einsetzt?
Those data should be stored in the NVM (non volatile storage). Afaik is this feature at the todo list, but not yet implemented.
Noch eines:
Antriebe von Rollläden, die von Shellies gesteuert werden sollen, in Reihenschaltung zu betreiben ist imho eine sehr schlechte Idee, es sei denn, du hast etliche Sensoren an den Rollladenführungen, was ich mal ausschließe. Hmm, vielleicht wäre auch eine Abstandsmessung möglich ... nur brainstorming
Die Shellies können die Positionierung selbstverständlich nur über Einschaltdauern realisieren - und btw dazu müssen sie auch immer mal wieder Referenzpunkte anfahren (ganz offen oder ganz geschlossen) - und sie müssen kalibriert werden, was ja bereits vorgesehen ist.
Wie aber können drei Rolllädenläufe zugleich kalibriert werden? Wenn es überhaupt gelänge, vielleicht möglich, wäre die Nutzung der Kalibrierung zumindest relativ unsicher.
Fazit: Jeder Rollladenantrieb ist einzeln zu betreiben und durch je einen Shelly anzusteuern.
Wenn die Rollläden unbedingt zugleich gefahren werden sollen, dann lässt sich dies per Szene (oder) per Nachrichten an alle beteiligten Shellies implementieren.
Mal ohne Einzelheiten, nur grobes Prinzip:
Auf dem i4 ein Skript erstellen mit der Implementation einer Schrittkettensteuerung.
Ob das auch per Szene in der Cloud ginge, weiß ich nicht.
Die Implementation per Skript würde ich hinkriegen. Allerdings habe ich dafür keinen Bedarf.
Nachgereicht:
Der i4 hat, wie der Name sagt, 4 Eingänge, kann also von 4 Tasten angesteuert werden. Willst du genau eine Taste von vier mit der gewünschten Funktionalität belegen oder nutzt du nur einen Eingang des i4?
Im zweiten Fall könnte es vielleicht für dich interessant sein, 4 Taster dafür einzusetzen.
Ich habe ein Skript erstellt, welches auf jede der 4 Tasten reagiert und die Dauern der Tastendrücke ausgewertet werden - statt Mehrfachdrücken. Das Skript ist durch Einträge darin konfigurierbar. Irgendwo in diesem Forum habe ich es zur Verfügung gestellt. Vermutlich kann es unter Skripte gefunden werden.
Problem: Wer Null Kenntnisse vom Programmieren bzw. von Datenstrukturen hat, wird sich damit nicht leicht tun.
Ein mit Tasmota geflashter Shelly kann das auch - ohne irgendeinen Cloud Account. Ich habe mich bisher nie dafür interessiert, wie dies erreicht wird, aber es funktioniert total verlässlich, wenn ein Zeitserver genutzt wird.
Schon deshalb erscheint mir der Cloud-Zugriff dafür unerheblich. Evtl. sind die Geodaten, einmal notiert, dafür einzutragen, so sicher weiß ich das nicht mehr.
Es sei die Frage gestattet, warum du bei einer Neu?)-Installation nicht gleich auch ein Computernetz aufgebaut hast bzw. aufbauen ließest und auf die Pro Linie der Shellies gesetzt hast. Funk ist nie so gut wie Leitungen - wenn Leitungen verlegbar sind.
Zu deinen Fragen:
zu 1. und 2. Die SSID der Shellies lassen sich in der aktuellen Firmware nicht ändern, was imho auch gut ist, da sie keine brauchbaren Accesspoints implementieren und nur als Notlösungen für entfernte Shellies einen Einsatzzweck haben. Namen kannst du aber zuweisen. Wenn die Shellies irgendwelche beobachtbaren Aktoren steuern/schalten, ist selbstverständlich eine solche Zuordnung möglich, wenn die Taster mit den Shellies fest verdrahtet sind, also keine "Intelligenz" wie einen Plus i4 besitzen.
zu 4. Wenn du dir das Menü auf den Websites der Shellies genauer ansiehst, wirst du erkennen, dass man vor "Password protected AP Network" einen Haken setzen kann und dann für dieses bandbreitenarme WLAN ein Kennwort festlegen kann. Dies erscheint mir für deine aktuelle Umgebung vor Ort als einziges zweckmäßig. Ich würde für alle diese Shellies das gleiche Kennwort vergeben.
zu 5. Ja klar, so als ob die Shellies soeben installiert worden wären. Man kann ja auch jeden Shelly bzgl. der Konfiguration in den Auslieferungszustand versetzen - wenn nicht komplett, dann zumindest so, dass man ihn neu einrichten kann.
Nur Punkt 4 erscheint mir beachtenswert. Alles andere kannst du sein lassen, solange dort noch kein Internetzugriff möglich ist. Ohne diesen Zugriff kannst du die Firmware nicht aktualisieren, was eine der ersten Aktionen sein sollte.
Vorgehensweise für jeden Shelly:
1. Mit dem Shelly eigenen WLAN verbinden, damit überhaupt konfiguriert werden kann.
2. Per Webbrowser die Website des Shelly laden, nicht die Shelly App dafür nutzen wollen!
3. Bei Bedarf erste kleine Funktionstests durchführen, aber nicht übertreiben.
4. Den Shelly mit dem vorhandenen LAN/WLAN verbinden/koppeln.
5. Die Firmware aktualisieren, Shelly rebooten.
6. Die erforderlichen weiteren Konfigurationen vornehmen.
7. Abschließende Funktionstests vornehmen.
8. Optional: Skripte erstellen ...
Empfehlung:
Verwende möglichst nicht diese merkwürdigerweise allzu oft eingesetzten Class C Netzadressen (192.168.xxx.yyy)! Setze am besten gleich auf Class B (172.16.xxx.yyy, statt 16 auch andere Werte möglich, aber nicht alle) oder Class A (10.xxx.yyy.zzz) Netzadressen. Das gibt dir für die Zukunft erheblich mehr Flexibilität. Und ich kann dir statische IP-Adressen empfehlen, die du vor deren Verwendung gut planen und dokumentieren solltest. Berücksichtige dabei, dass dein Netzwerk vielleicht so weit wachsen wird, wie du es dir gegenwärtig noch nicht vorstellen magst! Eine gute Planung darf Stunden oder Tage dauern, sie ist eine gute Investition, welche deine spätere Arbeit am Netzwerk unterstützen wird.
Na dann viel Spaß, Ausdauer und Experimentierfreude mit den Shellies, sie sind es wert
Nun, dein Verfahren per JSON.stringify() verwendet den kompletten String. Per includes() Methode kann nicht zwischen key und value unterschieden werden. Per Knoten switch und change werden eindeutig keys verwendet. Das macht das Vefahren robuster. Prinzipiell wäre ein value "switch:0" oder "switch:1" möglich, welcher per replace() in der Nachricht verändert würde. Das sind die Gründe, warum ich auf das Verfahren mit den Knoten setzen würde.
Hier meine 3 Knoten, allerdings für die MQTT Nachrichten von einem Plus H&T. Die Teile sollten für dich leicht anpassbar sein.
[
{
"id": "a795fdbf4b88cc48",
"type": "change",
"z": "1d57fbc98cc72f61",
"name": "temperature",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "payload.params.temperature:0.tC",
"tot": "msg"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 870,
"y": 420,
"wires": [
[]
]
},
{
"id": "933fce3faee525d2",
"type": "switch",
"z": "1d57fbc98cc72f61",
"name": "has key",
"property": "payload.params",
"propertyType": "msg",
"rules": [
{
"t": "hask",
"v": "temperature:0",
"vt": "str"
},
{
"t": "hask",
"v": "humidity:0",
"vt": "str"
}
],
"checkall": "true",
"repair": false,
"outputs": 2,
"x": 640,
"y": 440,
"wires": [
[
"a795fdbf4b88cc48"
],
[
"b7f8ead8af088ca7"
]
]
},
{
"id": "b7f8ead8af088ca7",
"type": "change",
"z": "1d57fbc98cc72f61",
"name": "humidity",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "payload.params.humidity:0.rh",
"tot": "msg"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 860,
"y": 480,
"wires": [
[]
]
}
]Ich habe hier noch nie einen JSON String aus Node RED hineinkopiert und weiß deshalb nicht, ob das so funktioniert. Nach einem gelungenen Test: Node RED -> Import, dort einkleben aus der Zwischenablage -> Import
Wenn du den JavaScript Quellcode bevorzugst, könnte vielleicht der von martner, Post #4, geeignet sein, allerdings würde ich diesen von unnötigem Müll (default ist überflüssig) befreien. Und dieser wäre für deinen Zweck anzupassen und zu erweitern.
Problem: Die Topics zu den Temperatur- und Luftfeuchtigkeit-Informationen von meinem Plus H&T sind andere.
Ich halte diese Notation mit dem Doppelpunkt auch für suboptimal, zumal im switch Objekt meiner Erinnerung nach die Id enthalten ist. Jedenfalls ist es beim Plus H&T mit temperature und humidity der Fall.
In meinen mJS Skripten für die Plus Geräte hatte ich auch damit zu kämpfen.
Du kannst statt deiner Funktion auch eine Kombination aus einem switch Knoten und zwei change Knoten verwenden.
Im switch msg.payload.params has key bzw. hat Schlüssel switch:0 auf Ausgang 1 und switch:1 auf Ausgang 2.
In den change Knoten sind bspw. msg.payload die Werte von msg.payload.params.switch:0 bzw. msg.payload.params.switch:1 zuzuweisen.
Dann braucht keine Konvertierung in einen string durchgeführt zu werden und du erhälts sofort den gewünschten Wert.
Falls der von mir notierte JSON Pfad nicht ganz stimmen sollte, wirst du ihn für deinen Zweck sicher anpassen können.
Sorry, ich habe überarbeitet. Ich testete es mit einer MQTT Nachricht von einem Plus H&T. has key funktioniert wohl nur mit einem einfachen Schlüssel, also nicht mit params.switch:0 ...
Verständlich
Wenn ich einen Assistenten einsetzen werde, wird es openHAB sein.
Bisher konnte ich alles, was ich implementieren wollte, mit Node RED schaffen - mit Einsatz von MQTT, HTTP und Influx -, auch ein Dashboard, welches meiner Frau zusagt und zu welchem sie aktiv Wünsche äußerte.