Status von Reedswitch an Shelly1

[mrb]

Hallo zusammen,

ja stimmt da war was mit den code-tags MEA CULPA. (Man ist einfach in zu vielen Foren unterwegs)
Sorry Beta-User

Bzgl Setter das war sehr hilfreich und genau das Putzelteil das Fehlte. *thumsup* Mit dem das das Icon passend zu offen/geschlossen (also invertierd) angezeigt wird kann ich leben. Danke nochmal

[mrb]

wie man mich kennt ich kommentiere für die nachwelt und falls ein anderer neuling das liest:
attr Shelly1Links webcmd on

damit ist es nur noch ein taster. next step icon entsprechend reading anzeigen. was ich gefunden habe https://forum.fhem.de/index.php?topic=28964.0
hoffe ich kapiere es richtig, denn Otto kennt sich gut aus ^^

[Beta-User]

denn Otto kennt sich gut aus ^^

Das stimmt definitiv!

wie man mich kennt ich kommentiere für die nachwelt und falls ein anderer neuling das liest:
attr Shelly1Links webcmd on

Für die Nachwelt würde ich eher folgendes empfehlen:

Code Auswählen Erweitern

attr Shelly1Links webcmd :
Wenn man es "richtig" macht, gibt nämlich meinem Gefühl nach das devStateIcon bereits die Funktionalität her, die man braucht, aber vermutlich weiß ich zu wenig, um das beurteilen zu können oder sinnvoll zu helfen .

[mrb]

okay verzweifle 
ich bekomme mein stateicon nicht hin
so wie ich otto versteht hat er das icon doch anhand eines reading gemacht. Aber was hat er damit definiert?

Code Auswählen Erweitern


define GaragenTor dummy
define di_garagentor DOIF ([RC81_1_TorOben:"closed"])(set GaragenTor open) DOELSEIF ([RC81_2_TorUnten:"closed"])(set GaragenTor closed)

ich stelle es mir doch so vor, aber korrigiert mich wenn ich falsch liege
wenn sein Garagentorkontakt RC81_1_TorOben "kontakt" hat dann wird eine Variable "GaragenTor" auf open gesetzt. Aber das ist 1. nur ein Dummy und nicht das Objekt selber und 2. nicht ein Objekt

und was bitte ist defmod?

Code Auswählen Erweitern

defmod nty_TorAuf notify GaragenTor:auf|VCCU_Btn4:trig_RC41_4:.*|VCCU_Btn4:trig_RC42_4:.* set SW81_1_TorAuf on-for-timer 1



und kann es vielleicht sein das objekte nicht verändert werden können? Mir dämmert da irgendwas vor zig Jahren das ich das mal gelesen habe

[Beta-User]

okay verzweifle 

...dann sind wir schon zu zweit ...

ich bekomme mein stateicon nicht hin

Vergiss das devStateIcon erst mal! (!!!)

Du brauchst zuerst ein hardwaremäßig funktionales Device. Ergo
- lieferst du eine Beschreibung des _gewünschten Schaltverhaltens_ des Relays. Vermutlich brauchst du einen Impuls?
- Schaust nach, wie du das ggf. DIREKT auf dem SHELLY umgesetzt bekommst (ganz ohne FHEM, aber auch ohne die Shelly-App!).

so wie ich otto versteht hat er das icon doch anhand eines reading gemacht. Aber was hat er damit definiert?

Das weiß ich auch nicht, aber ich bin ziemlich sicher, dass
a) ich keinen Bock habe, hier eine Flut von Devices zu sezieren, die man effektiv nicht braucht
b) das alles mit (nicht ganz trivialen) Einstellungen direkt im MQTT2_DEVICE zu machen ist...

Vielleicht reibst du an der Lampe und fragst Otto, wie er das heute lösen würde?

und was bitte ist defmod?

[/code]

Code Auswählen Erweitern

help defmodkönnte dir diese Frage vielleicht beantworten...

PS: Hier hatten wir mal was ähnliches mit Tasmota und zwei Reed: https://forum.fhem.de/index.php/topic,116968.0.html
Kann man zwar nicht 1:1 übertragen, aber als Steinbruch sollte es taugen...

[mrb]

...dann sind wir schon zu zweit ...
Vergiss das devStateIcon erst mal! (!!!)

Ja das ist alles nicht so leicht ^^

Du brauchst zuerst ein hardwaremäßig funktionales Device. Ergo
- lieferst du eine Beschreibung des _gewünschten Schaltverhaltens_ des Relays. Vermutlich brauchst du einen Impuls?
- Schaust nach, wie du das ggf. DIREKT auf dem SHELLY umgesetzt bekommst (ganz ohne FHEM, aber auch ohne die Shelly-App!).

hab ich doch! Korrekt in der MQTT des Shellys

PS: Hier hatten wir mal was ähnliches mit Tasmota und zwei Reed: https://forum.fhem.de/index.php/topic,116968.0.html
Kann man zwar nicht 1:1 übertragen, aber als Steinbruch sollte es taugen...

Ich schaue es mir später an, aber jetzt wird gegrillt

[Beta-User]

hab ich doch! Korrekt in der MQTT des Shellys

OK, auch wenn ich nicht so recht verstehe, was mit "in der MQTT des Shellys" gemeint sein könnte.

Wie auch immer: Dann bitte die eingehenden MQTT-Messages (Topic+Payload) je für einen der folgenden Vorgänge liefern:
- von auf nach zu
- von zu nach (ganz) auf
- beim Anhalten zwischendurch
(vermutlich wäre es wichtig zu wissen, wie lange das in etwa dauert. Die Zeitstempel musst du vermutlich aber gesondert aufnehmen, z.B. indem du die erzeugten Events in FHEM loggst).

Viel Spaß, auch beim Grillen!

[DetlefR]

Ich mische mich noch mal vor dem Urlaub ein.

Also was Otto gebaut hat kannst du so nicht nachbauen da er 4 Zustände darstellt. Auf(fahren), Zu(fahren) Open und Closed. Du hast nur den einen Kontakt. Da gibt es nur Open oder Closed.
Du könntest das DevStateIcon von MQTT2_shelly1_58BF25D82638 entsprechend anpassen.
Zuerst festlegen was "STATE" sein soll. Also in deinem Fall input_0

Code Auswählen Erweitern

attr MQTT2_shelly1_58BF25D82638 stateFormat input_0
Dann die Icon festlegen.

Code Auswählen Erweitern

attr MQTT2_shelly1_58BF25D82638 devStateIcon 0:fts_garage_door_10:zu 1:fts_garage_door_100:auf
Oder umgedreht. Das zu und auf vertauscht.
Zur Realisierung des Tasters. Ich würde auf dem Shelly unter Timer Auto-Off entsprechend setzen. Und nicht vergessen, unter Settings Button-Typ den Reed zu deaktivieren. Sonst fährt das Tor immer hin und her.
Was mir aber immer noch nicht klar ist. Wie sagst du dem Tor "Auf" oder "Zu". Ich vermute mal du kannst nur sagen "bewege dich". Die Richtung wird dann jeweils umgekehrt.

PS:

Wenn du meinem "Gemaule"-Link gefolgt wärst, wärst auch du im Wiki gelandet, ...

Du hast ja recht. Aber manchmal reicht es aus sich erst mal einen Überblick zu verschaffen worum es überhaupt geht.
Und fehlende Code tags bringen wenigstens lustige Smily   

[Beta-User]

Ich mische mich noch mal vor dem Urlaub ein.

Dann mal viel Spaß im Urlaub, erhol dich gut!

Schade, dass uns erst mal so ein kompetenter Einmischer verloren geht .

PS:Du hast ja recht.

Übrigens: Wenn du meinem "PS"-Link in meinem vorletzen Beitrag hier gefolgt wärst, wärst du auf einer interessanten Diskussion gelandet...
Und wenn du "erste Schritte" gelesen hättest (ebenfalls verlinkt), wäre dir vielleicht nicht entgangen, dass Reading-Namen bei MQTT2_DEVICE was ziemlich beliebiges sind...

@mrb:
Bitte lasse erst mal die "Kosmetik" weg, zu der auch "stateFormat" gehört... Wir werden erst mal überlegen, ob das, was DetlefR hier noch als "input_0" kennt, nicht besser in "state" aufgehoben wäre (allerdings nicht in einer simplen "offen/zu"-Logik durch direkte Übernahme).

[mrb]

Ich mische mich noch mal vor dem Urlaub ein.

Also was Otto gebaut hat kannst du so nicht nachbauen da er 4 Zustände darstellt. Auf(fahren), Zu(fahren) Open und Closed. Du hast nur den einen Kontakt. Da gibt es nur Open oder Closed.
Du könntest das DevStateIcon von MQTT2_shelly1_58BF25D82638 entsprechend anpassen.
Zuerst festlegen was "STATE" sein soll. Also in deinem Fall input_0

Code Auswählen Erweitern

attr MQTT2_shelly1_58BF25D82638 stateFormat input_0
Dann die Icon festlegen.

Code Auswählen Erweitern

attr MQTT2_shelly1_58BF25D82638 devStateIcon 0:fts_garage_door_10:zu 1:fts_garage_door_100:auf
Oder umgedreht. Das zu und auf vertauscht.
Zur Realisierung des Tasters. Ich würde auf dem Shelly unter Timer Auto-Off entsprechend setzen. Und nicht vergessen, unter Settings Button-Typ den Reed zu deaktivieren. Sonst fährt das Tor immer hin und her.
Was mir aber immer noch nicht klar ist. Wie sagst du dem Tor "Auf" oder "Zu". Ich vermute mal du kannst nur sagen "bewege dich". Die Richtung wird dann jeweils umgekehrt.

PS:Du hast ja recht. Aber manchmal reicht es aus sich erst mal einen Überblick zu verschaffen worum es überhaupt geht.
Und fehlende Code tags bringen wenigstens lustige Smily   

Okay habe mit deinem vorschlag rumgespielt (und ja ich möchte trotzdem das von beta-user noch umsetzen und schauen das man das logt (MQTT-Messages) . zwar bin ich mir 1000000% sicher das der reed input0 [und nicht input_0 ist] aber sicher ist sicher) und tada läuft 
werde heute mittag die geforderten logs schicken. Gibt es eigentlich ne möglichkeit das log (MQTT-Messages) über längere zeit aufzunehmen?

[TomLee]

Gibt es eigentlich ne möglichkeit das log (MQTT-Messages) über längere zeit aufzunehmen?

In FHEM -> am einfachsten die "Raw Payload" in ein Reading schreiben und das ganz normal mit FileLog loggen ?

Code Auswählen Erweitern

attr MQTT2_shelly1_58BF25D82638 readingList shellies/shelly1-58BF25D82638.* raw

Oder mit Hilfe von dem Atttribut rawEvents (am IO) die Rawevents im (gefilterten) Eventmonitor ausgeben lassen und später kopieren ?

Code Auswählen Erweitern

attr <IO> rawEvents shellies/shelly1-58BF25D82638.*

Bin gespannt welche Möglichkeit(eb) es noch (in FHEM) gibt.

[Beta-User]

In FHEM -> am einfachsten [...]

Thx. Eventuell hast du auch diesen dummy bereits mit der Frage nach den Laufzeiten zusammengebracht?

zwar bin ich mir 1000000% sicher das der reed input0 [und nicht input_0 ist]

Hihi, der Reed sollte halt m.E. direkt nach "state"... (aber nicht in jedem Fall gleich, daher der "pseudo-watchdog"-Hinweis von oben...) Dafür sollte das relay dort (state) raus.

[TomLee]

Thx. Eventuell hast du ...

Nö, ganz ehrlich, auch nach zwei/drei Mal (mit)lesen nicht verstanden wie ihr zwei auf einen Nenner kamt und es triggert mich zur Zeit (weil beschäftigt) auch Null (auch nach dem Hinweis nicht) es nachzuvollziehen ...