Hallo in die Runde,
bin langsam am verzweifeln, etliche Stunden probiere ich eine Wechselschaltung mit DOIF,notify
zu erstellen. Frage mich ob mein hohes Alter Schuld ist oder ich irgend etwas grundlegendes übersehe.
Zur Sache, am Garagentor ist ein 1Wire Schalter der mir das Reading sensed.A mit Wert 1 oder 0 liefert.
Am anderen Ende der Garage ist auch ein 1Wire Schalter der mir auch Reading sensed.A mit Wert 1 oder 0 liefert je nach Schalterstellung.
In meinen Augen könnte ein Problem das Pollen alle 3s bei 1Wire sein, aber der state bleibt aber nach jeden schalten entsprechend stehen also ändert sich entsprechend.
Frage mich, muss ich den Zustand(state) der Lampe on oder off auswerten geht, es auch nur über die Schalter alleine, auf event der Schalter reagieren oder den Zustand der Schalter auswerten usw. ?
Brauche ich mehrere DOIFs notifys etc.
Hier mal ein Versuch von vielen mit DOIF
([1WSchalter_ga_tuer:sensed.A:d] or [1WSchalter_ga_tor:sensed.A:d])
(IF ([Ga_Licht_Tor:state] eq "off") (set Ga_Licht_Tor on))
DOELSE
(set Ga_Licht_Tor off)
Möchte auch wie bei einer klassischen Wechselschaltung am selben Schalter das Licht an bzw. ausschalten.
Mir gehen leider nach suchen im FHEM Forum, KI suche etc. die Ideen aus,
kann mir jemand bitte unter die Arme greifen.
Mit freundlichen Gruß
Hans-Jürgen
Bauchgefühl sagt mir, dass das großgeschriebene IF an dieser Stelle falsch sein könnte.
Das IF ist ein FHEM Befehl und wahrscheinlich gar nicht das, was Du an der Stelle wirklich haben möchtest.
Was verstehst du unter Wechselschaltung?
Für mich bedeutet Wechselschaltung, dass ich an einer Stelle einschalten kann und dann an einer anderen Stelle ausschalten kann, unabhängig vom Zustand des jeweiligen Schalters.
Was du programmiert hast, ist: Sobald ein Schalter auf on geht, dann soll Licht einschalten, wenn es nicht an war. Wolltest du das?
Pseudocode für Wechselschaltung lt. ChatGPT:
if schalter1_geaendert oder schalter2_geaendert:
lampe = nicht(lampe)
"geändert" bedeutet irgendein Event und keine bestimmte Zustandsabfrage, also eher:
([1WSchalter_ga_tuer:"sensed.A"] or [1WSchalter_ga_tor:"sensed.A"])
(IF ([Ga_Licht_Tor:state] eq "off") (set Ga_Licht_Tor on) ELSE (set Ga_Licht_Tor off))
Attr do always
Zitatif schalter1_geaendert oder schalter2_geaendert:
lampe = nicht(lampe)
define n_wechsel notify 1WSchalter_ga_(tuer|tor):sensed.* set Ga_Licht_Tor toggle
Hallo Damian,
tut mir Leid!
Macht leider nur Disco paar Sekunden an ,dann aus und so on.
Hätte klassische Wechselschaltung besser definieren sollen.
Meinte wie in der Hausinstallation, wenn Dein Elektriker nicht wer weiß wie gepfuscht hat,
kannst Du an dem Schalter an dem Du das Licht eingeschaltet hast auch wieder aus schalten,
ohne von A nach B zu laufen.
Weiß als gelernter Elektriker wovon ich rede, sorry ist in meinem Haus auch so.
Hallo betateilchen,
habe das Notify schnell wieder gelöscht.
LED Strahler glimmt kurz auf und geht wieder aus mit ständiger Wiederholung.
Oder Strahler bleibt paar Sekunden an und geht wieder aus.
Von jedem Schalter aus einzeln zu schalten in meinen Anfangsversuchen hat soweit funktioniert,
also Hardware scheint somit in Ordnung nur an der Logik Umsetzung hapert es soweit.
Könnt Ihr das pollen zyklische ? von 1Wire Bus als Verdacht ausschließen?
Weiß aber trotzdem Eure Mühe Wert zu schätzen!!
Gruß Hans-Jürgen
eine klassische Wechselschaltung ist nur mit xor hinzukriegen, d.h. wenn beide Schalterstellungen "on" oder "off" haben, wird das Licht eingeschaltet und sofern beide eine Unterschiedliche Schalterstellung haben wird ausgeschaltet.
Fertigen Code kann ich gerade nichr Liefern, da ich kein fhem zum testen zur Hand habe.
Die Lampe hat keine Verbindung zu den Schaltern und umgekehrt? Alles passiert nur über FHEM?
Welche Events lösen die Schalter aus? Welche Readings haben sie (Status)?
Ich wüßte nicht was in dem Fall das notify von betateilchen permanent triggert.
Zitat von: Deckoffizier am 04 Dezember 2025, 11:34:43in Problem das Pollen alle 3s bei 1Wire sein
Außer Du lässt die Schalter permanet events feuern -> event-on-...?
-> Mehr Infos, bessere Hilfe
Zitat von: habl am 04 Dezember 2025, 14:10:34wenn beide Schalterstellungen "on" oder "off" haben
Das ist aber nicht klassisch.
https://www.zaehlerschrank24.de/pub/media/wysiwyg/FAQ/wechselschaltung/wechselschaltung_plan1.jpg (https://www.zaehlerschrank24.de/pub/media/wysiwyg/FAQ/wechselschaltung/wechselschaltung_plan1.jpg)
Hallo rabehd,
Danke erstmal...
Lampe und Schalter habe keine direkte Verbindung zu einander.
Lampe wird über ZWave geschaltet.
Reading sensed.A liefert nur 0 oder 1
hier mal ein List vom Schalter
Internals:
DEF 12.EC207D000000 10
FUUID 6927194b-f33f-cca1-db84-e5c39aa47615a651
IODev myOWServer
LAST_READ_FAILED 0
NAME 1WSchalter_ga_tor
NR 410
STATE sensed.A: 1 sensed.B: 0 alarm: 1
TYPE OWDevice
eventCount 1820
READINGS:
2025-12-03 18:22:08 IODev myOWServer
2025-11-29 11:27:22 PIO.A 0
2025-11-29 11:27:27 PIO.ALL 0,0
2025-11-26 20:19:56 PIO.B 0
2025-11-30 15:12:11 PIO.BYTE 0
2025-11-29 10:44:44 address 12EC207D00000018
2025-12-04 14:32:50 alarm 1
2025-12-01 20:42:44 channels 2
2025-12-01 20:42:16 crc8 18
2025-11-26 20:22:01 family 12
2025-11-27 09:28:05 latch.A 1
2025-11-27 09:28:12 latch.B 1
2025-12-01 20:38:56 latch.BYTE 1
2025-11-27 09:34:12 locator FFFFFFFFFFFFFFFF
2025-11-26 21:02:44 power 1
2025-11-26 21:12:43 r_locator FFFFFFFFFFFFFFFF
2025-12-04 14:32:50 sensed.A 1
2025-11-26 20:20:18 sensed.ALL 0,0
2025-12-03 18:22:04 sensed.B 0
2025-11-26 21:03:22 sensed.BYTE 0
2025-11-27 09:34:57 set_alarm 331
2025-12-04 14:32:50 state sensed.A: 1 sensed.B: 0 alarm: 1
fhem:
address 12.EC207D000000
alerting 1
bus bus.0
interfaces state
interval 10
getters:
PIO.A
PIO.ALL
PIO.B
PIO.BYTE
T8A/volt.0
T8A/volt.1
T8A/volt.2
T8A/volt.3
T8A/volt.4
T8A/volt.5
T8A/volt.6
T8A/volt.7
T8A/volt.ALL
TAI8570/pressure
TAI8570/sibling
TAI8570/temperature
address
channels
crc8
family
id
latch.A
latch.ALL
latch.B
latch.BYTE
locator
memory
pages/page.0
pages/page.1
pages/page.2
pages/page.3
pages/page.ALL
power
r_address
r_id
r_locator
sensed.A
sensed.ALL
sensed.B
sensed.BYTE
set_alarm
type
polls:
sensed.A
setters:
PIO.A
PIO.ALL
PIO.B
PIO.BYTE
latch.A
latch.ALL
latch.B
latch.BYTE
memory
pages/page.0
pages/page.1
pages/page.2
pages/page.3
pages/page.ALL
sensed.A
sensed.ALL
sensed.B
sensed.BYTE
set_alarm
state:
sensed.A
sensed.B
Attributes:
DbLogExclude .*
model DS2406
polls sensed.A
room Heizraum
sortby 1
uncached 1
Gruß
Hans-Jürgen
Von der Idee her liegt der Ansatz von betateilchen doch richtig.
Die Lampe / das Licht soll togglen wenn einer der Schalter den Zustand (0>1 / 1>0) wechselt (ähnlich wie mehrere Taster am Eltako Relais oder Wechsel-/Kreuzschaltung).
Das kann doch eigentlich nur schiefgehen wenn mehr als 1 Event beim Drücken kommt.
Zitat von: RalfRog am 04 Dezember 2025, 14:47:58Von der Idee her liegt der Ansatz von betateilchen doch richtig.
Die Lampe / das Licht soll togglen wenn einer der Schalter den Zustand (0>1 / 1>0) wechselt (ähnlich wie mehrere Taster am Eltako Relais oder Wechsel-/Kreuzschaltung).
Das kann doch eigentlich nur schiefgehen wenn mehr als 1 Event beim Drücken kommt.
Genau und selbst mehr als 1 Event gibt es nicht, eher ganz kurz nacheinander. Genauso als ob 2 Personen "gleichzeitig" drücken. Dann gibt es gleich wieder den Ausgangszustand.
Ich würde mal in den Eventmonitor schauen. Meine Vermutung, da kommen ständig welche. Also mal meinem Vorschlag folgen.
Hallo an Alle,
Ja rabehd Du scheinst den richtigen Riecher gehabt zu haben, im
Eventmonitor erscheinen zyklisch die Events von den 1Wire Schaltern.
Ist dann so ähnlich wie bei zyklisch sendenden Temperatursensoren.
Mal sehen wie ich damit umgehen kann/muss.
Gruß
Hans-Jürgen
Hallo,
Großes Danke an alle Beteiligte.
Ist schon fast wie Weihnachten ;)
Habe bei den Schaltern attr event-on-change-reading sensed.A gesetzt,
funktioniert mit dem notify von betateilchen bestens und schön kurz und knapp. Freu
Hatte ich wohl bei meiner Spielerei vorher wohl gelöscht.
Setze es damit auf gelöst.
Eine besinnliche Adventszeit wünscht
Hans-Jürgen
Hi
Abschließend noch ne Frage weil mich 1Wire interessiert hatte und du von Disco berichtet hast.
Die
DEF 12.EC207D000000 10definiert das Device und fragt alle 10sec ab mit entsprechender Aktualisierung der Readings/State.
Heisst das umgekehrt, dass du im schlechtesten Fall 10sec warten musst bis nach dem Schalten das System reagiert und das Licht anschaltet?
Gruß Ralf
Hallo Ralf,
zu Deiner Frage...
habe beim Busmaster Intervall auf 3s eingestellt.
Soweit ich mich richtig informiert habe ist 1Wire nicht unbedingt für Echtzeitanwendungen
gedacht?
Also nach dem Schalten geht das Licht wie gerade der Bus abgefragt gefühlt
fast gleich bis 1-2 Sekunden an, Zwave Funkübertragung liegt ja auch noch dazwischen.
Wenn es damit was zu tun hat steht beim Busmaster LAST_READ_FAILED auf 0.
Werde mal ausprobieren die Intervall Zeit zu verkürzen wie weit man dies ausreizen kann.
Diese Verzögerung stört mich in diesen Anwendungsfall nicht weiter, ehe das Garagentor auf ist, ist auch das Licht an und beim Verlassen eher angenehm.
Es gibt von Esera auch Busmaster die fast Modus können sollen, wenn ich das richtig verstehe, mal dort bei Interesse genauer nachfragen.
Für meinen Teil, hatte mal einen verbaut und war damit aus mehreren Gründen nicht zu frieden und habe ihn wieder entfernt und als Notfall Reserve rumliegen, obwohl mir die Hutschienenmontage sehr zusagt.
Jetzt habe ich die Schleuderschuhe an...
frage mich schon länger ob das schalten über iButton schneller ginge?
Aber das passt wohl besser alles in den 1Wire Forenbereich.
Es grüßt
Hans-Jürgen
Das Problem ist hier ganz klar 1-Wire. Denn wenn 1W-Devices am Bus hängen, und tatsächlich alle 3 Sekunden abgefragt werden, bedeutet das einen erheblichen Overhead auf dem Bus. Auch mit dem "fast"-Mode wird das in der Regel nicht besser werden. Ein iButton ist nichts Anderes als ein 1W-ID-Device, also "nur eine Seriennummer".
Es gibt aber einen Trick, den ich schon 2016 in den SmartHome Hacks beschrieben habe. Man lässt _eben nicht_ 1W-Devices permanent auf dem Bus. Sondern die Betätigung eines physisch vorhandenen Schalters bewirkt, dass ein 1W-Device _auf den Bus gelegt wird_. Dafür reicht ein ID-Device (oder ein iButton...) aus.
Der Busmaster kann hier alle 0,3-0,5 Sekunden pollen. Da er fast nie ein 1W-Device findet, gibt es keinen Overhead. WENN er dann eines findet, weiß er sehr schnell, um welches es sich handelt - und kann einen Schaltvorgang auslösen. Der Bus wird durch die 1W-Erkennung für ca. 1 Sekunde blockiert, das stört aber nicht.
Ich benutze diesen Trick, um mit iButtons mein Garagentor und auch Haus- und Hoftür zu öffnen, die Busmaster sind dabei jeweils Arduino Nano und pollen alle 0,3 Sekunden. Code dafür ist im FHEMWIKI unter "DoorPi und FHEM" zu finden.
Ausprobiert habe ich das auch mit Alarmkontakten für Fenster, das ist die Anwendung, die ich damals im Buch beschrieben habe. Wenn an jedem Fenster ein Kontakt mit integriertem 1W-ID-Device hängt, das bei Fensteröffnung auf den Bus gelegt wird, kann man mit einem einzigen 1W-Bus alle Fenster überwachen und sogar sehen, welches Fenster geöffnet wurde.
LG
pah
Zitat von: RalfRog am 05 Dezember 2025, 09:50:53isst das umgekehrt, dass du im schlechtesten Fall 10sec warten musst bis nach dem Schalten das System reagiert und das Licht anschaltet?
Ja.