Beiträge von Schubbie

Leider sieht man bei den Nodes immer nicht so richtig, was dahinter steckt. Aber du rechnest nun einfach nur Wert 2 - Wert 1? Wie wertest du das in Abhängig zu der Zeit aus? Das würde auch nur funktionieren, wenn ein Event ausgelassen wird, aber nicht, wenn jedes gesendet wird?

Vermutlich ist es leicht, ich habe jedoch nur den Node "Delta" nicht verstanden oder den richtigen Node nicht gefunden.

Nutze für den Test den Node MQTT-json, damit bekommst du direkt die Daten, an die du willst und brauchst nicht zusätzlich parsen, das macht der Node direkt.

Oben rechts die versuchte Auswertung per Unix-Zeit. Es läuft alles perfekt, also Logik des Dimmers nachgebildet, bis auf den Doublepush. Am einfachsten wäre es natürlich, wenn als Event ein Doublepush kommen würde, was der Dimmer intern ja beherrscht.

Die Shelly Plus können kein Coap mehr, daher wollte ich direkt darauf verzichten.

Das Topic vom event_cnt zu bekommen ist kein Problem.

Es geht mir hier reinweg um eine Lösung für Node Red. Wie ich es theoretisch löse ist mir bewusst, mir fehlen lediglich die korrekten Nodes, bzw. ob ich den Delta-Node dafür verwenden kann und diesen eventuell falsch angewandt habe.

Idee war halt, dass Topic A mit einem Delay um 400ms später aktualisiert wird und Topic B sofort. Wenn Topic B >1 zu Topic A, dann Brightness 100%, sonst nichts.

Ich hatte es ja auch schon mit der Differenz der Unix-Zeit von 2 eingegangen Events probiert, aber es wird halt häufig nur 1x gesendet oder beide zur selben Zeit.

Danke für die Mühen.

Das ist ein Abgleich, wie ich ihn vorgehabt habe, nur eben etwas anders in Node Red. Mir fehlt da ein entsprechender Node, der eine Wertänderung (Delta) innerhalb einer gewissen Zeit auswertet. Es soll per MQTT laufen, mit CoIoT wollte ich nicht arbeiten, da die neuen Shellies es nicht mehr unterstützen.

Ich habe probiert, ob ich den event_cnt auf 0 setzen kann, habe es aber nicht hinbekommen. Wenn ich den nach 400ms auf 0 setzen könnte, dann bräuchte ich nur auszuwerten, ob der Wert größer 1 ist.

Du kannst auch nochmals die L untereinander messen, die sollten 0 Ohm haben. Aber du schriebst, dass der Taster Spannung durchschaltet, von daher eher unwahrscheinlich. In dem Fall, dass ein L keinen Kontakt hat, könnte man einen anderen oder eine Wago nehmen, wenn man sich den Rückversand oder Löten sparen möchte.

Aber ganz zuvor mache die Messung nochmals auf der Einstellung "20M"...

Ja, auf Taster wechseln ist am sinnigsten. Wie willst du sonst dimmen, außer per Smartphone o.ä.?

Hättest du einfach das getestet, was ich geschrieben habe, dann hättest du gesehen, dass du den Taster falsch angeschlossen hast. Viele haben einen Schließer- UND Öffnerkontakt. Nimmt man den falschen Kontakt, dann wird immer ein Longpush beim Loslassen ausgeführt... Ich würde es ändern, dann brauchst du den Workaround mit dem "reverse inputs" nicht, zudem wird über einen geschlossenem Kontakt immer etwas Strom fließen, was vielleicht kaum messbar ist, aber man muss die Bauteile ja nicht unnötig belasten.

Wenn ich ein übergeordnetes System habe, wozu dann die Cloud? Man richtet es sich doch ein, um eben kein Cloud-Jünger zu sein?

Wer sich solch ein System einrichtet, der sollte auch in der Lage sein, sich einen VPN-Tunnel einzurichten, von Portfreigaben halte ich nicht so viel.

Mit dem Update 1.11.7 hat sich diesbezüglich nicht viel geändert. An Events gibt es immer noch nur "L" und "S". Es scheint aber so, als wenn schneller hintereinander weg Events gesendet werden können.

Wurde ein entsprechendes Event für einen Doublepush aus dem Shelly kommen, wäre es ein Traum.

Falls jemand eine Idee hat, wie man den event_cnt in Node Red entsprechend auswerten kann, würde es eventuell helfen. Theoretisch braucht es ja nur "wenn Wert innerhalb 400ms um 2 vergrößert, dann 100%". Ich dachte an den Delta-Node und wollte Topic A um 400ms per Delay verzögert aktualisieren, während Topic B den event_cnt sofort erhält. Muss ich mich wohl nochmals mit beschäftigen oder der Shelly liefert ein entsprechendes Event, bevor ich dazu komme. Zumindest spricht der ferngesteuerte Shelly direkt an, als der Ausgang des Shellies, an dem der Taster hängt und bisher funktioniert alles 1:1, bis auf den Doublepush mit 100%, aber der funktioniert ja auch direkt schon nicht zuverlässig

NEIN, natürlich klemmst du den Shelly für eine Widerstandsmessung ab!

Wenn offen, dann kann man von der Klemme bis zum nächsten erreichbaren Punkt messen und gucken, ob Verbindung oder ein Wackelkontakt besteht.

Ich tausche die um, wie sonst soll Allterco davon Wind bekommen, dass nicht vernünftig gelötet wird?

Das ist schwierig. Entweder öffnen oder messen. In eine Richtung sollte ein Widerstand im Megaohm-Bereich zwischen SW und L zu messen sein, wenn immer "OL" angezeigt wird, dann wird ein Defekt vorliegen.

Das geht so nicht, da der Shelly nicht weiß, ob der entfernte Shelly ein oder aus ist.

Auf detached mit den beschriebenen Actions (toggle) schaltest du den einen mit short an/aus und den anderen mit long an/aus.

Kannst du Mal bitte beschreiben, was du nun genau möchtest?

Toggle gibt an, dass bei jedem Druck abwechselnd ein-/ausgeschaltet wird. Von einem Timer war bisher nicht die Rede. Diesen kann man jedoch, wenn man nur einschalten und das Licht nach x Sekunden ausgehen soll, per Action mitsenden oder man stellt im Shelly "Auto Off" ein.

Beitrag

RE: Sammlung von HTTP-Befehlen

Inhalt:




#1 Shelly 1

#2 Shelly 2.5 als 2-fach Schaltaktor


#3 Shelly 2.5 als Rollladenaktor

#4 Shelly PlugS


#5 Shelly Bulb

#6 Shelly Duo und Duo GU10

#7 Shelly Dimmer und Dimmer2

#8 alle Shelly der Gen.1

#9 Shelly Motion

#10 Shelly Uni

#11 Shelly Pro 4PM




Bei passwortgeschützten Geräten sind im Befehl der IP-Adresse die Benutzerdaten voranzustellen, also:

(Quelltext, 1 Zeile)

user und passwort natürlich anpassen. 

Shelly 2.5:

als Rollladen-Aktor



Rollladen öffnen:

(Quelltext, 1 Zeile)

Rollladen schließen:

…

Gast10

20. September 2019 um 15:58

ich würde bei sowas auf "detached Switch" stellen und bei Shortpush den Toggle-Befehl an Localhost und bei Longpush an die IP des anderen Shellies senden.

Meine Homematic-IP regeln stufenlos. Wenn Shelly auch stufenlos regelt, dann dürfte die Isolierung nicht so die Rolle spielen, da nicht ständig auf- und zugefahren wird. Dazu bekommen wir aber bestimmt eine Rückmeldung.

kurz 10 Sekunden gegoogelt:

https://www.google.com/search?q=Gira+…KHfJIBCAQ_AUIBA

Bei Print-Worth-3D scheint es nichts zu geben.

Aber wozu Halter? Die Kabel halten die Shellies auch stramm hinter den Tastern.

Poste mal die Ausgabe des Browsers

[Shelly-IP]/status

um auszuschließen, dass der Taster als Öffner angeschlossen ist. Wenn du gedrückt hälst und den Browser aktualisierst, dann sollte der Input von 0 auf 1 gehen.

Ich hatte auch bereits welche mit schlechten Lötstellen, bei denen auf SW nichts eingegangen ist.

Und korrekt angeschlossen, also im Web-UI an dem Symbol und mit /status geprüft?

Zitat von Harry2009

,"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"source":"mqtt"}]

Steht doch in der Ausgabe

Liegen die Shellies an der selben Sicherung wie die Steckdose? Ansonsten wäre die Zuordnung der Sicherungen nicht eindeutig und somit nicht zulässig.

Beispiel:

Es wird die Spannungsfreiheit an der Steckdose festgestellt. Beim öffnen der N-Klemme führt dann jedoch der N, der vom Shelly kommt, Spannung, wodurch die Gefahr eines elektrischen Schlags besteht.

Sollte es auf dem Shelly zu einem Kurzschluss kommen und dieser auf der selben Phase, jedoch nicht auf der selben Sicherung, liegen und die Steckdose reizt den N bereits aus, dann kann es theoretisch passieren, dass die Sicherung nicht auslöst.