Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

Begonnen von edy_80, 25 Oktober 2020, 19:06:36

Vorheriges Thema - Nächstes Thema

SebastianStorb

#90
Ich wüsste gerne wie es genau umgekehrt funktioniert. Ich nutze FHEM und Tablet UI. Meine Klimaanlagen habe ich über HACS in Home Assistant eingebunden und kann diese dort auch von der Oberfläche steuern.
Entitäts-ID: climate.midea_ac_18691697794845
Über den MQTT-Explorer sehe ich, was ich aus FHEM sende. Jetzt verstehe ich nur nicht, was ich senden muss?

Versucht hatte ich:
fhem/climate/midea_ac_18691697794845/preset_mode 2
und vieles Andere in dieser Art.

In der configuration.yaml hatte ich ohne Erfolg folgendes versucht:

select:
    - platform: mqtt
      command_topic: fhem/climate/midea_ac_18691697794845
      name: dimstal
      #climate.midea_ac_18691697794845
      options:
        - preset_mode 1
        - preset_mode 2
        - preset_mode 3


in FHEM bekomme ich u.a. folgende Infos über die Anlage im MQTT-Client
2021-09-15 19:51:27   fan_modes_1     Auto
     2021-09-15 19:51:27   fan_modes_2     Full
     2021-09-15 19:51:27   fan_modes_3     High
     2021-09-15 19:51:27   fan_modes_4     Medium
     2021-09-15 19:51:27   fan_modes_5     Low
     2021-09-15 19:51:27   fan_modes_6     Silent

    2021-09-15 19:44:26   midea_ac_18691697794845-current_temperature 21.0
     2021-09-15 19:44:26   midea_ac_18691697794845-fan_mode "Auto"
     2021-09-15 19:44:26   midea_ac_18691697794845-friendly_name "KlimaanlageSebastian"
     2021-09-15 19:44:26   midea_ac_18691697794845-last_changed 2021-09-15T17:38:52.203079+00:00
     2021-09-15 19:44:26   midea_ac_18691697794845-last_updated 2021-09-15T17:44:26.568485+00:00
     2021-09-15 19:44:26   midea_ac_18691697794845-max_temp 30
     2021-09-15 19:44:26   midea_ac_18691697794845-min_temp 17
     2021-09-15 19:44:26   midea_ac_18691697794845-outdoor_temperature 19.0
     2021-09-15 19:44:26   midea_ac_18691697794845-preset_mode "none"
     2021-09-15 15:48:19   midea_ac_18691697794845-restored true
     2021-09-15 19:44:26   midea_ac_18691697794845-state off
     2021-09-15 19:44:26   midea_ac_18691697794845-supported_features 57
     2021-09-15 19:44:26   midea_ac_18691697794845-swing_mode "Both"
     2021-09-15 19:44:26   midea_ac_18691697794845-target_temp_step 1.0
     2021-09-15 19:44:26   midea_ac_18691697794845-temperature 18.0
     2021-09-14 20:58:49   midea_ac_18691697794845_preset_mode 2
   
     2021-09-15 19:51:27   hvac_modes_1    auto
     2021-09-15 19:51:27   hvac_modes_2    cool
     2021-09-15 19:51:27   hvac_modes_3    dry
     2021-09-15 19:51:27   hvac_modes_4    heat
     2021-09-15 19:51:27   hvac_modes_5    fan_only
     2021-09-15 19:51:27   hvac_modes_6    off


Ich habe gestern Abend so vieles versucht, dass HASS heute morgen nicht mehr lief und ich den ganzen Nachmittag nochmal neu aufgesetzt habe. Jetzt traue ich mich nicht mehr so viel zu probieren.

Im Log vom HASS ist scheinbar nie etwas angekommen - nur wie gesagt einfach nicht mehr gelaufen.

Könnte mir jemand helfen?

Beta-User

Du solltest zu dem Thema einen neuen Thread aufmachen, und dann VOLLSTÄNDIGE Informationen liefern - Auszüge sind mehr oder weniger unnütz, weil nicht klar ist, wo was herkommt und wie es ggf. durch json2nameValue() ausgepackt wurde; wir werden vermutlich MQTT-Rohdaten brauchen, wie sie z.B. über mosquitto_sub zu bekommen sind.
Das sieht mir nach komplexeren JSON-Strukturen aus, die da versendet werden müssen.
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

SebastianStorb

Ok, ich werde einen neuen Beitrag schreiben. Tut mir Leid, wenn es nicht verständlich geschrieben ist. Ich verstehe nur viel zu wenig über Home Assistant, MQTT und vor allem die Bridge in FHEM bzw.auch Mosquitto. Das ist mehr oder weniger ein Wunder, dass ich das überhaupt irgendwie zum Laufen bekommen habe. Als ich die Wiki-Artikel gelesen habe, die darüber geschrieben wurden komme ich schon nach den ersten Absätzen schon ins Stocken (weil ich keine Ahnung habe was dort beschrieben wird) und verstehe gar nichts mehr. Die Schnipsel, die ich hier zusammengetragen habe sind hilflose Versuche gewesen irgendetwas von Fhem nach HASS zu schicken. Es wird also noch dauern, bis ich so weit bin überhaupt die Frage richtig zu formulieren und die erforderlichen Informationen dazuzuschreiben.

Danke für die Unterstützung,

(Meine Posts zu diesem Thema können gerne einfach von einem Admin gelöscht weden)

gadget

Poste hier bitte einen Link auf den neuen Thread wenn der fertig ist, dann schaue ich mir das gerne an. Vielleicht ist so etwas komplexes wie die Steuerung einer Klimaanlage auch nicht unbedingt die beste Wahl für den Einstieg, probier es doch erst mal mit einfacheren Dingen (Temperatursensoren, Schalter, Dimmer).

Ich nehme an, dass es für deine Klimaanlage eine fertige Integration in HA gibt und Du diese (evtl. sogar per Autodiscovery) verwendet hast ? Dann ist das per se erst mal ein climate-Device, aber nicht vom Typ platform: mqtt, sondern irgendwas Herstellerspezifisches (Übersicht der Integrationen siehe https://www.home-assistant.io/integrations/#climate)

Du kannst aber per MQTT Statestream https://www.home-assistant.io/integrations/mqtt_statestream/ dafür sorgen, dass alle Informationen von beliebigen Integrationen, die Du in fhem brauchen kannst, per MQTT in Richtung fhem gesendet werden. Allerdings ist es dann bei komplexen Devices nicht trivial, ein passendes MQTT2_DEVICE in fhem zu basteln, dass die MQTT Nachrichten dann korrekt in Readings umsetzt.

Die Klimaanlage dann von fhem aus zu steuern ist dann noch mal eine ganz andere Sache, hier wirst Du vermutlich am ehesten Erfolg haben, wenn Du Dir zusätzlich ein (Pseudo-) climate-Device vom Typ MQTT anlegst, dies von fhem aus schaltest und dann schließlich mit  HA-Automatisierungen dafür sorgst, dass das "echte" climate-Device das gleiche macht.

Wenn es in fhem eine gutes Modul für deine Klimaanlage gibt würde ich überlegen dieses parallel zu HA zu nutzen. So mache ich das bei meiner Daikin auch. Die kommt gut damit zurecht gleichzeitig von fhem und von HA angesprochen zu werden.

Shortie

Erst einmal Danke für die vielen wertvollen Informationen. Damit habe ich bereits erfolgreich die Verbindung über MQTT hinbekommen.

Was ich nun gerne noch erreichen möchte ist das autodiscovery von HA für MQTT zu nutzen, da man nur so ein Gerät in HA für MQTT Geräte anlegen kann und auch das automatische setzen des Raums funktioniert nur über Discovery. Dafür wird eine config Nachricht benötigt. Die Idee ist das diese von den einzelnen Geräten in fhem mit retain gesendet werden. Über mosquitto_pub habe ich dasganze auch schon erfolgreich hinbekommen.
Allerdings habe ich noch keine Möglichkeit gefunden diese aus fhem zu senden.
fhem könnte diese beim erstellen/ändern oder sobald fhem die Verbindung zum Broker aufbaut senden, dank retain sollten sie ja auf dem mqtt Broker erhalten bleiben und damit auch nach einem HA neustart weiterhin für das discovery zur Verfügung stehen.

Beta-User

Zitat von: Shortie am 08 November 2021, 20:13:45
Was ich nun gerne noch erreichen möchte ist das autodiscovery von HA für MQTT zu nutzen, da man nur so ein Gerät in HA für MQTT Geräte anlegen kann und auch das automatische setzen des Raums funktioniert nur über Discovery. Dafür wird eine config Nachricht benötigt. Die Idee ist das diese von den einzelnen Geräten in fhem mit retain gesendet werden. Über mosquitto_pub habe ich dasganze auch schon erfolgreich hinbekommen.
Vermutlich wäre es auch hierfür sinnvoll, einen neuen Thread zu starten, und dazu v.a. auch für die, die HA nicht kennen zu zeigen, wie sowas aussehen muss...

Zitat
Allerdings habe ich noch keine Möglichkeit gefunden diese aus fhem zu senden.
Prinzipiell unterstützen alle MQTT-Interface-Module in FHEM z.B. auch das direkte publishen von Infos.

Zitat
fhem könnte diese beim erstellen/ändern oder sobald fhem die Verbindung zum Broker aufbaut senden, dank retain sollten sie ja auf dem mqtt Broker erhalten bleiben und damit auch nach einem HA neustart weiterhin für das discovery zur Verfügung stehen.
Dazu müßte aber v.a. klar sein, was wohin unter welchem Namen gesendet wird. V.a. für wildcard-Readings ist das uU. einem gewissen Wandel unterworfen, und es ist nicht immer klar, welcher Datentyp sich hinter welchem Reading verbirgt, usw., usf..

Sehr vielleicht könnte man ein stark erweitertes "get <mgb> devinfo" basteln, aber dazu müßte sich jemand mal hinsetzen und erst mal exemplarisch ein, zwei Geräte "darstellen".
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

Shortie

Ich habe hier https://forum.fhem.de/index.php/topic,124018.0.html dazu einen neuen Thread gestartet und ein Beispiel geliefert.

In den MQTT-Interface Modulen hatte ich noch nicht geschaut, da war ich vermutlich zu sehr auf MQTT_GENERIC_BRIDGE innerhalb des Device fokussiert bisher. Generell ergibt es meiner Meinung nach aber Sinn sowas an den Geräten selbst zu haben, siehe auch den neuen Thread.

jazzor

#97
Hallo zusammen,

auch wenn ich hier gerade den Grabräuber spiele, bitte ich um Vergebung, da meine Frage in dieses Thema einfach am Besten passt:

Ich versuche gerade meine Rolladen, welche in Fhem stecken, in HomeAssistant sinnvoll zu nutzen.
Die grundsätzliche Funktionalität (auf/stop/zu) bekomme ich hin.
Lediglich mit den Positionen habe ich Probleme und hoffe, dass mir einer der Gelehrten hier weiterhelfen kann:
Dies ist die Definition eines meiner Rollos in Fhem:
defmod Rollo_Nr_14 ROLLO
attr Rollo_Nr_14 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Rollo_Nr_14 autoStop 1
attr Rollo_Nr_14 commandDown {RolloIo("14","down")}
attr Rollo_Nr_14 commandStop {RolloIo("14","stop")}
attr Rollo_Nr_14 commandUp {RolloIo("14","up")}
attr Rollo_Nr_14 devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop position-100:fts_shutter_100:open position-90:fts_shutter_80:closed position-80:fts_shutter_80:closed position-70:fts_shutter_70:closed position-60:fts_shutter_60:closed position-50:fts_shutter_50:closed position-40:fts_shutter_40:open position-30:fts_shutter_30:open position-20:fts_shutter_20:open position-10:fts_shutter_10:open position-0:fts_shutter_10:closed
attr Rollo_Nr_14 excessBottom 4.4
attr Rollo_Nr_14 excessTop 0
attr Rollo_Nr_14 genericDeviceType blind
attr Rollo_Nr_14 group Rollos
attr Rollo_Nr_14 homebridgeMapping clear\
CurrentPosition=homekit_pos,minValue=0,maxValue=100\
TargetPosition=homekit_pos,minValue=0,maxValue=100,minStep=10,delay=400,cmd=position_homekit,\
PositionState=state,values=/^drive-up/:INCREASING;;/^drive-down/:DECREASING;;/.*/:STOPPED
attr Rollo_Nr_14 mqttForward all
attr Rollo_Nr_14 mqttSubscribe state:stopic={"$base/set"}
attr Rollo_Nr_14 resetTime 0
attr Rollo_Nr_14 room HASS,Interfaces->homekit,Obergeschoss->Schlafzimmer,fhem->Alexa
attr Rollo_Nr_14 secondsDown 22.0
attr Rollo_Nr_14 secondsUp 26.8
attr Rollo_Nr_14 switchTime 1
attr Rollo_Nr_14 type normal
attr Rollo_Nr_14 webCmd open:closed:half:stop:position

setstate Rollo_Nr_14 position-60
setstate Rollo_Nr_14 2022-03-14 17:03:35 command position-60
setstate Rollo_Nr_14 2022-03-14 17:03:35 desired_position 60
setstate Rollo_Nr_14 2022-03-14 17:03:35 drive-type modul
setstate Rollo_Nr_14 2022-03-14 17:03:41 homekit_pos 40
setstate Rollo_Nr_14 2022-03-14 17:03:35 last_drive drive-down
setstate Rollo_Nr_14 2022-03-14 17:03:41 position 60
setstate Rollo_Nr_14 2022-03-14 17:03:41 state position-60


Ich nutze (bewusst) eine alte, leicht modifizierte Rollo-Version, weil ich meine Rolladen seit Ewigkeiten über eine gehackte Fernbedienung steuere. Damals war die Definition von auf und zu noch anders, als sie in Homekit war, weshalb homekit_pos die korrekte Position des Rollos ist.

Auf der Homeassistant-Seite sieht das Ganze so aus:

cover:
  - platform: mqtt
    name: Fhem_Rollo_14
    unique_id: "fhemRollo14"
    command_topic: "fhem/Rollo_Nr_14/set"
    state_topic: "fhem/Rollo_Nr_14/state"
    position_topic: "fhem/Rollo_Nr_14/homekit_pos"
    set_position_topic: "fhem/Rollo_Nr_14/set"
    set_position_template: "{{'position_homekit '}}{{ position }}"
    #availability_topic: "fhem/connection/status"
    payload_available: "true"
    payload_not_available: "false"
    payload_open: "open"
    payload_close: "closed"
    payload_stop: "stop"
    state_opening: "drive-up"
    state_closing: "drive-down"
    position_open: 100
    position_closed: 0
    optimistic: false
    qos: 1

Mit dieser Konfiguration kann ich in der Richtung HA->Fhem die Position exakt einstellen.
1. Problem: Ich will die Position in 10% Schritten einstellen.
2. Problem: Ich bekomme zwar auf dem Topic fhem/Rollo_Nr_14/homekit_pos die Position zurück, aber in HA wird diese nicht korrekt grafisch angezeigt. Hier steht immer noch "Schließt " als state. Wie kann ich das einstellen?

Danke für die Hilfe!

Dominik83

Hallo Zusammen,

ich habe seit Jahren FHEM laufen und probiere mich zur Zeit mal mit Home Assistant. Da ich meine DOOYA Rolläden wohl nicht so einfach direkt mit HA verheiratet bekomme wird FHEM wohl weiterhin nicht zu ersetzen sein. Eventuell gibt mit die MQTT Bridge aber die Möglichkeit beides zu kombinieren.

Ich habe jetzt mal den "demoswitch" von Gadget und das "PC Licht" von Daim21 nachgebaut. Bei beiden Devices kommt mein schalten aus FHEM in HA an.
Wenn ich aber in HA schalte springt der Schalter nach einer Sekunde wieder zurück und in FHEM passiert nichts - das gleiche verhalten was hier schon ein paar mal beschrieben wurde.

Meine Generic Bridge sieht so aus:

Internals:
   DEF        mqtt room=HASS
   FUUID      62659733-f33f-96ca-bbd7-622bbcbf44eeba1c
   IODev      ha_MQTT2
   NAME       mqttGeneric
   NR         24
   NTFY_ORDER 50-mqttGeneric
   STATE      in: 75 out: 9 devices: 0
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    room=HASS
   prefix     mqtt
   CHANGED:
     incoming-count: 44
     incoming-count: 45
     incoming-count: 46
     incoming-count: 47
     incoming-count: 48
     incoming-count: 49
     incoming-count: 50
     incoming-count: 51
     incoming-count: 52
     incoming-count: 53
     incoming-count: 54
     incoming-count: 55
     incoming-count: 56
     incoming-count: 57
     incoming-count: 58
     incoming-count: 59
     incoming-count: 60
     incoming-count: 61
     incoming-count: 62
     incoming-count: 63
     incoming-count: 64
     incoming-count: 65
     incoming-count: 66
     incoming-count: 67
     incoming-count: 68
     incoming-count: 69
     incoming-count: 70
     incoming-count: 71
     incoming-count: 72
     incoming-count: 73
     incoming-count: 74
     incoming-count: 75
   READINGS:
     2022-04-24 22:59:50   device-count    0
     2022-04-24 23:10:25   incoming-count  75
     2022-04-24 23:03:13   outgoing-count  9
     2022-04-24 23:03:13   transmission-state outgoing publish sent
     2022-04-24 22:59:50   updated-reading-count 0
     2022-04-24 22:59:50   updated-set-count 0
   devices:
     :global:
       :publish:
         *:
           mode       R
           topic      {"fhem/$device/$reading"}
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
Attributes:
   IODev      ha_MQTT2
   globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
   globalPublish *:topic={"fhem/$device/$reading"}
   icon       mqtt_bridge_2
   room       MQTT
   stateFormat in: incoming-count out: outgoing-count devices: device-count
   verbose    5


MQTT2_Client so:

Internals:
   BUF       
   DEF        192.168.178.231:1883
   DeviceName 192.168.178.231:1883
   FD         9
   FUUID      6265959e-f33f-96ca-973e-c0c9eebd9e85ca29
   NAME       ha_MQTT2
   NR         21
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhemdev
   lastMsgTime 1650834710.16311
   nextOpenDelay 5
   qosCnt     11
   qosMaxQueueLength 100
   READINGS:
     2022-04-24 22:59:50   state           opened
   qosQueue:
Attributes:
   clientId   fhemdev
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       MQTT
   username   openmqtt
   verbose    5


Der demoswitch:
Internals:
   FUUID      62659733-f33f-96ca-e55b-c377d267c3c4b9a5
   NAME       demoswitch
   NR         27
   STATE      off
   TYPE       dummy
   READINGS:
     2022-04-24 22:53:00   state           off
Attributes:
   mqttForward all
   mqttSubscribe state:stopic={"$base/set"}
   room       HASS,Test
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   verbose    5
   webCmd     on:off


und mein PCLICHT so:
Internals:
   FUUID      6265ba46-f33f-96ca-36d0-7fa81ad5515726cf
   NAME       PCLicht
   NR         30
   STATE      an
   TYPE       dummy
   READINGS:
     2022-04-24 23:03:13   state           on
Attributes:
   devStateIcon an:li_wht_on aus:li_wht_off
   eventMap   on:an off:aus
   group      Beleuchtung
   icon       light_office_desk
   mqttForward all
   mqttPublish *:topic={"$base/$device/$name"}
   mqttSubscribe state:stopic={"$base/$device"}
   room       Arbeitszimmer,HASS,alexa
   setList    on off
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
   webCmd     on:off



In der HA Conf steht folgendes:

switch:
  - platform: mqtt
    name: demoswitch
    command_topic: "fhem/demoswitch/set"
    state_topic: "fhem/demoswitch/state"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    #availability_topic: "fhem/connection/status"
    #payload_available: "connected"
    #payload_not_available: "disconnected"
    optimistic: true

  - platform: mqtt
    name: PCLicht
    command_topic: "fhem/PCLicht/set"
    payload_on: "on"
    payload_off: "off"
    state_topic: "fhem/PCLicht/state"
    state_on: "on"
    state_off: "off"
    availability_topic: "fhem/connection/status"
    payload_available: "connected"
    payload_not_available: "disconnected"
    icon: "mdi:desk-lamp"



Fällt jemandem hier ein Fehler auf?

Vielen Dank vorweg
Dominik




Beta-User

Zitat von: Dominik83 am 24 April 2022, 23:18:30
Fällt jemandem hier ein Fehler auf?
MAn. sind hier gleich mehrere Dinge "verbogen":
- prinzipiell ist "globalPublish" nicht zu empfehlen!
- "device-count" mit 0 ist komisch, das CHANGED-Array sollte leer sein. Das deutet auf irgendwas sehr Seltsames in deiner Konfiguration hin. Ist alles aktuell?
- Dann sind die "subscribe"-Angaben für beide dummy unterschiedlich, "richtig" dürfte
mqttSubscribe state:stopic={"$base/set"}
sein (iVm. dieser unglücklichen nicht nach sub und pub geteilten Einstellung für $base in der MGB selbst).
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

Dominik83

Hi Beta,

danke für deine Unterstützung. Es tut nun: Update war das Stichwort! Verrückt, zum testen habe ich gestern einen neuen Container mit dem neusten Image von Dockerhub gemacht da dachte ich ein Update sei nicht nötig.

Wieder was dazu gelernt!

Danke!

Beta-User

Nun ja,
ein "update" ist mAn. immer Pflicht nach einer Neuinstallation (wenn man nicht grad das nightly-deb genutzt hat), aber erst mal ist ja schön, dass es nun eher läuft wie erwartet.

Bedeutet aber nicht, dass meine anderen Hinweise nicht auch ernst gemeint gewesen waren, insbesondere zu "globalPublish"...
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

Dominik83

Hi,

ich habe das Global Publish entfernt und das publish auf dem Device "Demoswitch" angepasst ---> klappt.

Als nächstes möchte ich meine Rollos ins HA bringen. Meine MGB zeigt auch:
D_Rollo6D
  publish:
    *                => fhem/D_Rollo6D/* (mode: R; qos: 0; retain)
  subscribe:
    state            <= fhem/D_Rollo6D/set (mode: S)


Interessanterweise kommt vom Rollo aber nichts bei meinem MQTT Broker an. Also das Topic "D_Rollo6D" erscheint da gar nicht.
Habe alles durchgestartet - geupdated habe ich ja gestern:-)

Das Rollo ist so definiert:

Internals:
   CHANNEL   
   DEF        0001100000000111100000101011
   FUUID      5c9e6500-f33f-9eb1-3523-c14aff76b2f30d5b
   ID         0001100000000111100000101011
   IODev      SIGNALESP1
   NAME       D_Rollo6D
   NR         196
   STATE      open
   TYPE       Dooya
   exact      open
   move       off
   position   0
   CODE:
     1          0001100000000111100000101011
   READINGS:
     2022-04-26 22:11:54   IODev           SIGNALESP1
     2022-04-26 22:18:18   exact           open
     2022-04-26 22:18:18   position        0
     2022-04-26 22:18:18   state           open
Attributes:
   IODev      SIGNALESP1
   SignalRepeats 10
   channel    6
   devStateIcon .*closed:fts_shutter_100 .*open:fts_window_2w
   event-on-change-reading state
   eventMap   on:Runter off:Hoch stop:Stop
   mqttForward all
   mqttPublish *:topic={"$base/$name"}
   mqttSubscribe state:stopic={"$base/set"}
   room       hass,Dominik,alexa
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   webCmd     Runter:Hoch:Stop:pos



Hast Du da noch einen guten Tip?

Danke Dir!

Dominik

Beta-User

Zitat von: Dominik83 am 26 April 2022, 22:27:39
ich habe das Global Publish entfernt und das publish auf dem Device "Demoswitch" angepasst ---> klappt.
Soweit so gut.

Zwei Anmerkungen dazu:
- das dann durch "pauschale publishes" in den einzelnen Devices zu ersetzen, ist nicht unbedingt Ziel der Übung, ich würde auch immer die publishes beschränken auf die Readings, die es "wirklich braucht". Was das bei deinem Rollladen wäre, musst du selbst wissen; wenn der "state" auf der Gegenseite mit numerischen Werten ausreichend beschrieben ist, würde ich nur das senden, und ggf. dann auch ein anderes Reading dahin umbiegen. Könnte sein, dass "position" dafür geeignet wäre...
- Meine Empfehlung wäre, "$base" global in Sende- und Empfangsrichtung unterschiedlich zu belegen, also in sub: gleich das "/set" mir reinzubasteln. (Deine anderen Angaben da sind auch überdenkenswert; es gibt dazu irgendwo auch eine separate Diskussion, vermutlich im "attrTemplate für MGB"-Thread).

Zitat
Als nächstes möchte ich meine Rollos ins HA bringen. Meine MGB zeigt auch:
Das sieht "eigentlich" (s.u.) ok aus, kann keinen Grund zur Annahme erkennen, dass es ein prinzipielles Problem gäbe.

Zitat
Das Rollo ist so definiert:

Internals:
   TYPE       Dooya
   event-on-change-reading state
   eventMap   on:Runter off:Hoch stop:Stop
   mqttForward all


Hast Du da noch einen guten Tip?
Ob gut, sei mal dahingestellt...

a) help Doyaa liefert für "state" als Setter on+off. Ich würde dazu neigen, (nur) den "pos"-Setter zu nutzen, und notfalls ein "richtiges" eventMap zu basteln, das die Sonderfälle "on/off" via MQTT mit abbildet - oder eben eine Verarbeitungsroutine (expression) für numerische set-state-Eingänge festlegen. Solche "Spezialitäten" waren/sind der Grund, warum ich mal vorgeschlagen hatte, attrTemplate für MGB einzubauen. Damit könnte man sowas wie einen "Standard" für Gegenstellen etablieren, bei denen praktisch alle FHEM-Rollladen-Devices "von außen" gleich zu bedienen wären. Es hat sich nur keiner die Mühe gemacht, den Faden für "seine" TYPE aufzugreifen...

b) Das eventMap ist vermutlich eher hinderlich - ich habe das aber nicht im Detail untersucht, Bauchgefühl sagt: es wird die "komplexe Form" benötigt, commandref zu diesem Attribut sollte weiterhelfen.

c) Das "event-on-.*"-Attribut kommt mir auch vom Baufgefühl her unpassend vor. (Entweder unnötig oder unvollständig.)

d) mqttForward all ist afaik der default für alles, was nicht dummy ist => unnötig (mAn. sollte man immer alles weglassen, was unnötig ist).
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

Dominik83

Hi Beta,

das pauschale publish aller readings nehme ich mir nochmal zu herzen.

Irgendwie publishen die Dooya Devices aber gar nichts.
Ich habe nochmal ein neues Device in der minimal Konfiguration angelegt um mögliche event-map Probleme auszuschließen:

Internals:
   CFGFN     
   CHANNEL    6
   DEF        0001100000000111100000101011_6
   FUUID      6269ad62-f33f-9eb1-005b-e235f75667ebdfd4
   ID         0001100000000111100000101011
   IODev      SIGNALESP1
   NAME       D_Rollotest
   NR         61194
   STATE      open
   TYPE       Dooya
   exact      open
   move       off
   position   0
   CODE:
     1          0001100000000111100000101011_6
   READINGS:
     2022-04-27 22:53:54   IODev           SIGNALESP1
     2022-04-27 22:56:11   exact           open
     2022-04-27 22:56:11   position        0
     2022-04-27 22:56:11   state           open
Attributes:
   mqttPublish *:topic={"fhem/$device/$reading"}
   mqttSubscribe state:stopic={"$base/set"}
   room       hass


In der MGB erscheint es auch:
D_Rollotest
  publish:
    *                => fhem/D_Rollotest/* (mode: R; qos: 0; retain)
  subscribe:
    state            <= fhem/D_Rollotest/set (mode: S)



Ich kann die Rollos per publish aus dem Broker heraus steuern, das subscribe funktioniert also.

Die Rollos Publishen aber nichts einfach gar nichts.

Da ich testweise auch nochmal andere Devices ins MQTT aufgenommen habe und alle sich beim Broker "melden" scheint es irgendwie an dem Dooya Modul zu liegen. Ich forsche nochmal weiter...

Grüße