AttrTemplate und Sprachassistenten

Begonnen von justme1968, 31 März 2019, 16:23:19

Vorheriges Thema - Nächstes Thema

justme1968

das attribut ist nur nötig wenn man die events auch an amazon schicken möchte um damit eine routine auszulösen.

aktivieren geht nur über das attribut im device. das attribut im alexa-device ist nur zum zeitweisen globalen deaktivieren.

die meisten bewegungsmelder und kontaktsensoren sollten automatisch erkannt werden. wenn nicht müsste das setzen von gnericDeviceType schon helfen. erst wenn das nicht reicht ist homebridgeMapping nötig.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Hmm, wie soll ich das deuten...?

Das klingt danach, als wäre das mit den "proactive events" eigentlich eine Art "Experteneinstellung", die man gar nicht über templates abbilden sollte?
(Ich werd's kommentarlos wieder ausbauen, wenn mir keiner in den Arm fällt, der es besser weiß).

Ansonsten würde ich die Zahl der "sensor"-templates auf zwei festlegen, nämlich eines, das nur via parametriertem Aufruf den genericDeviceType festlegt und ein zweites, das dann zusätzlich auch das komplette Mapping empfangen kann?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Hi Andre,

kannst du das mal ansehen: https://forum.fhem.de/index.php/topic,108999.msg1031171.html#msg1031171

(Kurzfassung: Erwünscht wäre  eine Funktion in siri.pm, die den "siri-Raum" in die raum-Liste eines bestimmten Devices aufnimmt, den Raum aus der config.json liefert oder den aufbereiteten neuen Attributinhalt. Sowas in diese Richtung halt...).

siri_add_siriroom_to_rooms(<devicename>)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

sorry. stehe gerade auf dem schlauch. was meinst du mit siri raum?

geht es darum ein device automatisch in den filter aus dem config.json zu bekommen?

wenn ja: das ist schwierig. der filter ist ja flexibel und kann alles mōgliche sein. ein raum, ein attribut, der device name, ... oder eine kombination als allem. also alles was laut devspec erlaubt ist. d. h. auch regen und filter.

dazu kommt dann noch das es pro config file mehr als eine connection zu fhem geben kann mit jeweils einem eigenen anderen filter und sogar mehr als ein config file bzw. homebridge instanz.  letzteres ist nötig weil pro homekit bridge nur 50 bzw. aktuell 100 devices oder services möglich sind.

(ich verwende z.b. pro raum eine eigene connection mit passendem namen um im log gleich zu sehen um welchen raum es gerade geht und zähle die devices einzeln oder in gruppen auf. )

eine beliebige bestehende konfiguration automatisch so zu ändern das genau ein device zusätzlich eingebunden wird ist so gut wie unmöglich.

erschwerend kommt hinzu das für siri
die default config noch nicht automatisch erzeugt wird und dir wiki beispiele von anfang anders als das config.sample file das ich mit ausliefere waren.

ich habe gerade keine gute idee wie wie hier etwas automatisieren können  das auch für bestehende installationen gilt.


vielleicht hilft erst mal drûber schlafen.

eventuell wird das ganze etwas einfacher wenn mir endlich eine gute varaiante einfällt die mehreren potentiellen instanzen per autostart aus fhem heraus zu steuern.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

...puh, sehr abstrakt (ich bin bekennendermaßen auf dem Spracherkennungsauge blind, und was Äpfel angeht, auch noch taub...)

Kurz: ich habe den Eindruck langsam erahnen zu können, wie diffus das ganze zu greifen ist. Die Idee von TomLee war in der Tat, den "filter" anzuzapfen und dazu die Datei zu lesen. Dass das nur funktionieren kann, wenn dort eindeutige Angaben stehen, ist soweit einleuchtend, aber wenn filter devspec ist, kann man das mMn. im Rahmen von attrTemplate fast nicht mehr abbilden. Das wäre dann ggf. Aufgabe spezieller Dialogfelder und Routinen.

Drüber schlafen (würde vorschlagen: mehr wie einmal...) ist vermutlich hier erst mal eine gute Idee :) .

Bin ja erst mal sehr zufrieden, dass die Basis soweit funktioniert, dass Leute u.a. deswegen AttrTemplate-Unterstützung in ihre Module einbauen. Falls du da noch irgendwelche Anregungen hast, wäre es nett, wenn du die loswirst, bevor sich zu viele Leute an den jetzigen Stand gewöhnt haben ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files