@Asgothian said in Touch-Lichtschalter?:

• Gibt es Wechselschaltungen ?

Nicht da, wo die Schalter zum Einsatz kommen, also: Nein

• Was hast Du an Leitungen am Schalter ? Nur eine zu schaltende Phase, oder Phase und Null ?

N, L1 und P (hab erst vor 2 Jahre überall wo kein 5x1.5 benötigt wurde 3x1.5 verlegt)

• Was hast du für Lampen die du schalten willst ?

Überall kommen LEDs zum Einsatz. Meistens GU10, aber auch E27. Auf jeden Fall keine Trafos. Alles 230V

• Was sollen es für Schalter sein ? Aus Erfahrung: Touch sieht toll aus, ist aus meiner Sicht aber mist - keine Rückkoppelung ob du "getroffen" hast, insbesondere im Dunkeln

Da hast Du Recht ...

• Sind Taster ok, oder müssen es Wippen bleiben

Es ist egal. Wenn ich einen „normalen“ Taster von Busch-Jäger, ohne dafür im Schaltschrank ein Relais einbauen zu müssen nehmen kann, dann wäre das sogar perfekt. Ich glaube, wenn das ginge, dann wäre die Variante Taster + Shelly die beste Lösung.

• muss das schalten zwingend auch gehen wenn dein ioBroker nicht läuft

Oh ja... mehr als zwingend notwendig.

• müssen es zu 100 % kauflösungen sein oder ist ein gewisses Mass an "basteln" gestattet

Basteln ist natürlich auch ein Option, aber gerade in der Küche sollte es schon ordentlich aussehen und 100% funktionieren.

• Müssen sie sich in ein vorhandenes "Schalterdesign" einpassen ?

Siehe weiter oben. Am besten: ja.

@da_Woody, glaube ich nicht.
Werde es aber heute noch prüfen. Da kommt der Shelly 2.5 auf dem Testtisch...

@jleg sagte in NodeJS Versions Problem bei NSPANEL Script:

@dark-angel
das sieht mir nach einem Bug im Nspanel-Script aus - das prüft die Nodeversion über system.host.*.nodeCurrent - es gibt zwar einen Dp ‚npmCurrent‘, der für Node heisst aber anders (kannst du im Expertenmodus in deinem Objektbaum prüfen)..

Danke @JLeg.
Wieder was gelernt...

Also: da diese Proxmox-CT mittlerweile die 3. Installation ist, bei der ich einfach die Backups der Vorgängermaschinen nach der Installation importiert habe (Raspberry Pi3 > Raspberry Pi4 > Proxmox), scheint bei jeden Import die "alte" Installation als Host unter "system.host." mit erstellt worden zu sein.
Dadurch scheint das Script etwas durcheinander zu kommen, da es unter "system.host.*.nodeCurrent" bei mir 3 Hosts findet.

Die überflüssigen Hosts gelöscht, ioBroker neu gestartet und siehe da: Keine Fehlermeldung mehr, das NodeJS veraltet ist.
Mal sehen, ob irgendwelche andere Instanzen, oder Scripte damit ein Problem haben, dass ich die "alte" Hosts gelöscht habe...

Vielleicht könnte trotzdem das Script dahingehend etwas "verbessert" werden, damit es wirklich nur die NodeJS Version des Hosts prüft, auf dem es läuft.

Danke euch allen, dass Ihr euch so intensiv um eine Lösung bemüht habt.

@tt-tom sagte in NSPanel - Hardwarebuttons und MQTT Problem:

Rule2 1

Also... Hirn eingeschalten, nachgeschaut und schon hat es funktioniert:

Rule2 on Button1#state do Publish SmartHome/%topic%/tele/RESULT {"CustomRecv":"event,button1"} endon on Button2#state do Publish SmartHome/%topic%/tele/RESULT {"CustomRecv":"event,button2"} endon

Rule2 1

Jetzt bleibt nur noch (zumindest für mich) die Frage zu klären, wieso der NSPanel in der Konsole nichts mit %prefix% anzufangen weiß.

P.S. Hätte mir viel Nachdenken erspart, hätte ich in dem Kapitel etwas besser aufgepasst: NSPanel-Tasmota-FAQ#1-hardware-buttons
Dort wird nirgends der %prefix% erwähnt.
Ich glaube, die Kurze Info im TrueScript sollte dahingehend überarbeitet werden.
Zeile 130:

129 Tasmota Konsole:
130   Rule2 on Button1#state do Publish %topic%/%prefix%/RESULT {"CustomRecv":"event,button1"} endon on Button2#state do Publish %topic%/%prefix%/RESULT {"CustomRecv":"event,button2"} endon
131   Rule2 1 (Rule aktivieren)
132   Rule2 0 (Rule deaktivieren)

An dieser Stelle möchte ich mich recht herzlich bei @TT-Tom für die Unterstützung bedanken.

Hi Leute,
seit geraumer Zeit habe ich das Problem, dass beim betätigen der Hardwarebuttons der Status unter 0_userdata.0.NSPanel.1.Relay.1 nicht aktualisiert wird, was dazu führt, dass weder die Symbole in den oberen Ecken in Screensaver den geänderten Zustand anzeigen, noch der richtige Status im Jarvis angezeigt wird.
Wenn ich die Softwareschalter unter Einstellungen benutze, wird auch der Status unter 0_userdata.0.NSPanel.1.Relay.1 richtig geändert und auch in Jarvis richtig angezeigt. Auch wenn ich über Jarvis die Schalter die Schalter betätige wird der Status unter 0_userdata.0.NSPanel.1.Relay.1 und in den oberen Ecken am Dysplay richtig angezeigt.
In alle Fälle gehen jedoch die Lichter ganz normal an und aus.
Habe die Tage erst das Script auf Version 4.0.4 ( auch TFT 50 und BerryDriver 8 ) aktualisiert, in der Hoffnung, dass es wieder funktionieren wird, aber dem war leider nicht so.

Hat jemand eine Tipp?

Erster (mehr, oder weniger) Erfolg, erzielt durch folg. Blockly:

Shelly Output ist "momentary" mit invertet Input
So wird das Licht auch ohne ioBroker funktionsfähig bleiben, nur eben ohne den Zusatz des Longpushs.
Wenn Output auf "detached" gesetzt würde, geht das Licht wenn Longpush erkannt wurde, oder aber eben beim loslassen an (in etwa wie "momentary_on_release" bei Shelly Gen.1). Nachteil: Wenn keine Kommunikation mit ioBroker, dann bleibt es dunkel.

@paul53
Das Problem ist, dass Event immer 3 Meldungen ausgibt (3 Zustände hintereinander)
Wenn ich Event triggere ist der erste Zustand immer "btn_down".
Bei SinglePress kommt erst "btn_up" und dann bleibt Event bei "single_push" stehen.
Anders allerdings bei LongPress: da kommt als nächstes "long_push" und zum Schluss bleibt es bei "btn_up" stehen.
Wenn ich zu 100% sicher wäre, dass die letzte Meldung bei LongPress immer "btn_up" sein wird, dann könnte ich das in mein Script einbauen (Event Auswertung mit kleine Verzögerung um sicher zu stellen, dass alle Eventmeldungen schon durch sind?).
Der Ursprung der "Geschichte" ist HIER nachzulesen. Das Shelly die Logic geändert hat finde ich persönlich nicht sehr prickelnd, aber die werden sich schon was dabei gedacht haben...

@paul53

Bzw.:

@oliverio
Einzeln. So schnell kann ich gar nicht schauen, wie sich der Wert ändert ...

@oliverio
Die Ausgabe ist aus dem Debugfenster auf dem Shelly kopiert.

Die Idee mit dem Script geht schon in der Richtung wie ich mir die Lösung des Problems vorstelle.
Muss dann heute Abend gleich mal herumexperimentieren...

Danke für den Richtungsanstoß.

@paul53
Der Datenpunkt in ioBroker (über den Shelly Adapter) heist direkt Event:

shelly.0.shellyplus2pm#9015068820c0#1.Input0.Event

Da werden direkt hintereinander die 3 Meldungen aus dem Eröffnungspost quitiert.

@martinp
wie werte ich das letzte Event aus?
Die "IF...THEN.." Schleife wird bei Änderung im Event aktiviert, also praktisch bei der ersten Änderung und nicht bei der letzten.
Ich könnte zwar das Script erst dann "aktivieren", wenn ein "short_push", oder "long_push" Event ausgelöst wird, ist aber für eine Schleife unbrauchbar und ich müsste 2 Scripte erstellen um die jeweiligen Events entsprechend abzufangen und damit dann mein Schindluder betreiben.

@oliverio
Genau das ist ja die Frage...
Wie filtere ich in eine "IF...THEN..." Schleife den richtigen Event?
Die Schaltzustände werden in wirklich kürzeste Zeit hintereinander im Event angezeigt.

Da sich die Logic beim Shelly Gen.2 gegenüber der Gen.1 etwas geändert hat, bin ich auf der Suche nach eine Lösung für folgendes Problem:

Bei Gen.2 wurden ein paar Datenpunkte zusammengeschmissen, was eben dazu führt, dass z.B. ein Longpush nicht mehr mit true, oder false hinterlegt wird, sondern in einen Event zusammen mit dem Button-Status zusammengeschmissen wird.
So z.B. sieht ein short_push aus:

  {
    "ts": 1736716265.022,
    "level": 2,
    "data": "shelly_notification:208 Event from input:0: {\"component\":\"input:0\",\"id\":0,\"event\":\"btn_down\",\"ts\":1736716264.99}",
    "fd": 1
  },
  {
    "ts": 1736716265.188,
    "level": 2,
    "data": "shelly_notification:208 Event from input:0: {\"component\":\"input:0\",\"id\":0,\"event\":\"btn_up\",\"ts\":1736716265.17}",
    "fd": 1
  },
  {
    "ts": 1736716265.51,
    "level": 2,
    "data": "shelly_notification:208 Event from input:0: {\"component\":\"input:0\",\"id\":0,\"event\":\"single_push\",\"ts\":1736716265.49}",
    "fd": 1
  },

und so ein long_push:

 {
    "ts": 1736716271.118,
    "level": 2,
    "data": "shelly_notification:208 Event from input:0: {\"component\":\"input:0\",\"id\":0,\"event\":\"btn_down\",\"ts\":1736716271.10}",
    "fd": 1
  },
  {
    "ts": 1736716272.116,
    "level": 2,
    "data": "shelly_notification:208 Event from input:0: {\"component\":\"input:0\",\"id\":0,\"event\":\"long_push\",\"ts\":1736716272.10}",
    "fd": 1
  },
  {
    "ts": 1736716273.469,
    "level": 2,
    "data": "shelly_notification:208 Event from input:0: {\"component\":\"input:0\",\"id\":0,\"event\":\"btn_up\",\"ts\":1736716273.45}",
    "fd": 1
  },

Hat jemand eine Idee, wie ich diese sich innerhalb von Millisekunden ändernde Events auswerten kann um short- und long-push zu triggern?

@dr-bakterius
Ich habe "detached" mit Absicht nicht gewählt, denn das Licht sollte auch dann Ein-/Ausgeschaltet werden können, wenn keine Verbindung zu ioBroker bestehen sollte. Das "Problem" habe ich mit dem NS Panel von Sonoff im Wohnzimmer.
Solange keine Verbindung zu ioBroker besteht sitze ich völlig im dunkeln, wenn ich nicht vorher das Licht eingeschaltet hatte.
Als ich das damals eingerichtet hatte, war "momentary" praktisch DIE Einstellung, wenn man einen Taster verwendet.
momentary_on_release verhindert, dass ein toggle ausgelöst wird, bevor man den Taster loslässt. Bei mir unbedingt erforderlich um den Longpush auswerten zu können.

Bei dem Gen.2 Shellys (habe einen Shelly 1 Gen.2 und jetzt noch den Shelly 2PM Gen.2) gibt es keinen EventCount und kein Longpush, womit mein Script praktisch unbrauchbar geworden ist, solange man kein Gen.1 Gerät damit steuert/auswertet.