devstate Icon von einem anderen Device

Begonnen von kmidt, 28 Dezember 2020, 09:51:14

Vorheriges Thema - Nächstes Thema

kmidt

Hallo zusammen,

ich habe 2 Devices.

Ich würde gerne bei Device A das devstate Icon ändern, wenn bei Device B sich der State verändert.

Wie mache ich das ?

Danke und lieben Gruß,
Andreas

Beta-User

Falls (!) man sowas braucht: ggf. über einen Eventhandler, z.B. notify.

Klingt aber nach einem "da ist was anderes faul"-Lösungsansatz.

Für weitere Hilfe wie üblich: list der beteiligten Geräte und hier zusätzlich vielleicht ein paar Takte, warum das notwendig sein soll.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

kmidt

Sehr gerne :

Ich habe am Garagentor einen Relay welches ja nur auf und zu machen kann ohne übermitteln zu können ob Garagentor auf oder zu ist.
Dafür habe ich einen Fensterkontakt der meldet ob auf oder zu ist.
Ich habe das im Moment so gelöst, dass ich mir unter dem Garagentor Device den Status anzeigen lasse (siehe Bild).
Das Garagentor steuere ich dann mit dem Devstateicon und im Hintergrund das Relay getriggert.
Nun möchte ich wenn das Garagentor auf ist ein anderes Devstateicon haben wie wenn zu.
Der Status selber ist aber ja beim Fensterkontakt und nicht beim Relay.


Beta-User

Hm, okay, also wirklich zwei physisch getrennte Devices.

list wären immer noch interessant, denn bei manchen Geräten kann man ggf. auch anders tricksen. Aber ohne das würde ich auf den Fensterkontakt ein notify legen, das dann "das Garagentor" via _setreading_ auf "geschlossen" setzt.

Man könnte auch versuchen, das ganze in eine Readingsgroup zu visualisieren, es gibt dafür afaik Beispielcode  im MySensors-Bereich (über die "angepinnten" zu finden).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

kmidt

Danke Dir schon einmal

Ich gebe ja beim devicestate Icon einfach an :

state:dann das Icon

Gibt es keine Syntax das man auf ein externes Device verweisen kann

"externes Device:state" : Icon


Beta-User

Doch. "Vorbehandlung" via stateFormat (z.B. Perl-ReadingsVal oder set magic-Ausdruck).

Das Problem: ohne dass es einen Trigger innerhalb des "Zieldevice" gibt, wird weder devStateIcon noch stateFormat evaluiert.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

#6
Ich habe ein ähnliches "Problem" bzw. einen ähnlichen Wunsch ;)

Ich habe ein speedtest-Device und eine Internet-Überwachung.

Jetzt will ich beim speedtest-device sehen, ob das Internet verbunden ist und beim Klick auf das Icon einen statusRequest auslösen (->speedtest).

Ich habe es wie folgt (ohne notify).

Ein userReadings beim PRESENCE-Device:
EDIT: wäre dann dein offen/geschlossen?


forward {my $value=ReadingsVal($name,"state","n.a."); fhem("sleep 0.1; setreading dsl_speedtest presence $value"); return "done"}


EDIT: statt dem userReadings hier geht nat. (bzw. ist verm. zu empfehlen ;)  ) ein notify! Ich wollte mir nur ein notify "sparen"... Wichtig bei userReadings (normalerweise) einen Trigger angeben! Ist hier da es sich um "state" handelt nicht einfach möglich!? Und da beim PRESENCE-Device (mit event-on-change-reading .* ) eh nur absent/present kommt und ich ja genau das weitergeben will/wollte auch "unnötig"... Wollte es nur geschrieben haben!!

Damit wird dann der Präsenz-Status an das dsl_speetest Device weitergegeben.
EDIT: das wäre dann dort wo du das Tor auf/zu machen kannst?

D.h. am Präsenz-Device sehe ich durch das neue Reading "forward" dass und wann weitergegeben wurde (nebensache)...

Und am dsl_speedtest-Device habe ich nun ein neues Reading presence wo eben der Status der Internet-Präsenz drin steht.
EDIT: du hättest dann eben bei deinem "Steuer-Device" ein weiteres Reading (Name kannst/musst du halt anpassen) wo eben offen/geschlossen oder open/closed oder was auch immer steht...

Darauf habe ich dann mit Perl eben entsprechend ein devStateIcon "gebastelt".
Farbe abhängig vom Präsenz-Status und bei Klick eben einen statusRequest...
EDIT: ok nicht auf Präsenz sondern auf den "running-Status" aber das liesse sich leicht anpassen...


devStateIcon {my $value=ReadingsVal($name,"state","n.a.");if($value eq "ok"){return "present:it_internet\@green:statusRequest absent:it_internet\@red"}elsif($value eq "running"){return "present:system_fhem_reboot\@orange"}else{return "present:message_attention\@orange:statusRequest absent:message_attention\@red"}}


und dann noch das Reading presence und weitere Infos per stateFormat:


stateFormat presence
</br>Download: download</br>
Upload: upload</br>
Ping: ping</br>
last_run

EDIT: stateFormat wirst du (verm.) nicht brauchen. Ich wollte halt mehr Infos stehen haben :)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

userReadings für "fremde" Devices finde ich persönlich nicht so toll, aber "state" ist auch nur ein Reading und wird triggernd aktualisiert....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

Ja, drum ja die Anmerkungen.
Ist halt ein Device weniger (für mich so übersichtlicher)...

Hmm, irgendwo hab ich (glaube ich mich zu erinnern) mal eine "besonderheit" bzgl. state und userReadings was mitbekommen...

Es ist ja schon bei notify "besonders"...

Aber schaue ich mir mal an...
(wobei wie geschrieben im aktuellen Fall auch unnötig. Es gibt ja nur state und presence. Beides wird "zeitgleich" aktualisiert und genau das will ich ja auch "übertragen")

Aber ob userReadings (missbrauchen) oder notify: ohne mehr Infos (in Form von lists) kann man (also ich) eh nicht mehr machen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)