Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

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

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: jensorium am 22 Februar 2021, 06:52:52
Hey. Unter userattribute on Schrank ist er auch drin. Wie auch bei anderen Usern so gesehen grade.


attr mqttGeneric mttqForward all

Hier steht mttq und nicht mqtt aber so oder so nimmt er das nicht.
Gruß
Warum gehst du mit den Attributen so frei um, versuchst aber nicht das, was in der commandref steht, nämlich das Attribut da zu setzen, wo es vorhanden ist: Am zu überwachenden/steuernden Gerät... Wurde doch hier schon geschrieben (ohne Hervorhebung)
Zitat von: gadget am 22 Februar 2021, 02:58:55
Ich glaube das liegt am fehlenden mqttforward all bei deinem schrank-dummy.

Zitat von: jensorium am 21 Februar 2021, 21:26:16
Ich glaub ich besorg mir besser par zigbee Dosen und gut, dann hab ich die Fehlerquelle MQTT hin und her weniger :(
Funk ohne Rückkanal ist nicht mehr zeitgemäß, und ein Teil der Probleme kommt auch daher, dass du irgendeine PI-GPIO-Lösung zu nutzen scheinst, die für sich genommen schon schwierig ist. Frage mich, warum du eingangs  einen NanoCUL erwähnt hattest. Wären das "normale IT-Geräte" (InterTechno-Protokoll via CUL) gewesen, wäre der Hackel vermutlich gar nicht erst entstanden.
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

hckoe

Hast Du ein globales mqttPublish in der MGB definiert, denn im Device selbst ist ja keines? Der mqttPublish wird benötigt, daß der Status an HA gesendet wird.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Beta-User

Zitat von: hckoe am 22 Februar 2021, 11:05:04
Hast Du ein globales mqttPublish in der MGB definiert, denn im Device selbst ist ja keines? Der mqttPublish wird benötigt, daß der Status an HA gesendet wird.
Guter Hinweis!

@jensorium: Bitte aber KEIN globales publish angeben, (auch) das sollte mAn. immer am Device (=> "schrank") konfiguriert werden...
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

jensorium

Hey Beta User,

erstmal Danke.
Da du vollkommen recht hast mit nicht mehr Zeitgemäß hab ich mir nun Zigbee sachen bestellt.

Dennoch versuche ich zu verstehen:

Besagte Zeile habe ich aus dem 2. Beitrag, hier war mir gestern der vermeintliche Typo aufgefallen, der aber keine Besserung brachte, auch mit ? und google finde ich leider nichts zu mqttForward oder mttqForward.

Ich habe geschaut und es ist im dummy schrank vorhanden, wie in der Liste zu sehen von gestern abend. Da ist es also drin, weiß nicht wo ich dann frei damit umgehe? Habe nun unter userattr und auch unter Attribute mgttForward drin. Bei Schrank.

Ja ich hab da eine GPIO lösung genutzt, das war so gewachsen, da ich dann das Intertechno System bekam und nen Nanocul bin ich mit dem Intertechno darüber gegegangen.

Jetzt versteh ich grad noch weniger:
Schrank und demoswitch machen state und set nun richtig (ON OFF), hier hab ich das GPIO Modul aber abgeklemmt, denke aber die würden schalten.

Mein WZ IT macht wenn ich es aus FHEM schalte state on off, wenn ich aus HA schalte set ON OFF aber es ändert sich nicht :(
Hier habe ich aber keinen Dummy genutzt

defmod wz IT 00111100010000111101111110 0 0000
attr wz userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long room_map structexclude
attr wz IODev traxCUL
attr wz mqttForward all
attr wz mqttSubscribe state:stopic={"$base/set"}
attr wz room GoogleAssistant,HASS,IT,wz
attr wz webCmd on:off

setstate wz off
setstate wz 2019-04-15 00:26:11 group 0
setstate wz 2019-04-15 00:26:11 protocol V3
setstate wz 2021-02-22 11:18:54 state off
setstate wz 2019-04-15 00:26:11 unit 0000



Wieso kann ich das WZ nicht so steuern?


Gruß
Jens




jensorium

Zitat von: Beta-User am 22 Februar 2021, 11:10:56
Guter Hinweis!

@jensorium: Bitte aber KEIN globales publish angeben, (auch) das sollte mAn. immer am Device (=> "schrank") konfiguriert werden...

Danke ihr zwei,

doch ich hatte ein Globales publisch in der mqttGeneric, hab das aus dem Beitrag oben so genommen:

globalPublish *:topic={"fhem/$device/$reading"}

Gruß

Beta-User

Zitat von: jensorium am 22 Februar 2021, 11:41:14
Danke ihr zwei,

doch ich hatte ein Globales publisch in der mqttGeneric, hab das aus dem Beitrag oben so genommen:

globalPublish *:topic={"fhem/$device/$reading"}

Gruß
Dann wirf es raus und mach die (eingeschränkten!) Publishes nur an die Devices, die du auch extern brauchst. Wie oft muss man denn schreiben, dass es Unsinn ist, ALLES in die Welt zu pusten...?
Meine Empfehlung ist, an der Bridge nur globalDefaults zu setzen, siehe dazu das attrTemplate "base_settings_to_MQTT_GENERIC_BRIDGE"
Vermutlich brauchst du für state@wz auch ein passendes publish, damit das an den richtigen Topic geht. Leider ist es bei diesen ganzen Bruchstücken, die du lieferst überhaupt nicht nachvollziehbar, was du wie gesetzt hast...
Jedenfalls ist "all" für alles, was nicht dummy ist der default für "mqttForward" (=> man braucht es nur da!).
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

jensorium

Hey Beta User,

ich versuche mal überblick zu schaffen, was brauchst du sonst noch?

Meine wz:
last Input device ist angeblich mgtt, aber ohne funktion
defmod wz IT 00111100010000111101111110 0 0000
attr wz userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long room_map structexclude
attr wz IODev traxCUL
attr wz mqttForward all
attr wz mqttSubscribe state:stopic={"$base/set"}
attr wz room GoogleAssistant,HASS,IT,wz
attr wz webCmd on:off

setstate wz off
setstate wz 2019-04-15 00:26:11 group 0
setstate wz 2019-04-15 00:26:11 protocol V3
setstate wz 2021-02-22 11:57:16 state off
setstate wz 2019-04-15 00:26:11 unit 0000



mein Client:
defmod ha_MQTT2 MQTT2_CLIENT 192.168.178.57:1883
attr ha_MQTT2 alias ha_MQTT2
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 keepaliveTimeout 60
attr ha_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr ha_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr ha_MQTT2 qosMaxQueueLength 100
attr ha_MQTT2 room MQTT
attr ha_MQTT2 username hamqtt

setstate ha_MQTT2 opened
setstate ha_MQTT2 2021-02-22 11:48:33 state opened


meine bridge:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HASS
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric alias mqttGeneric
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0

setstate mqttGeneric in: 103 out: 93 devices: 3
setstate mqttGeneric 2021-02-22 11:48:33 device-count 3
setstate mqttGeneric 2021-02-22 11:59:04 incoming-count 103
setstate mqttGeneric 2021-02-22 11:57:16 outgoing-count 93
setstate mqttGeneric 2021-02-22 11:57:16 transmission-state outgoing publish sent
setstate mqttGeneric 2021-02-22 11:16:59 updated-reading-count 0
setstate mqttGeneric 2021-02-22 11:49:48 updated-set-count 81




Ich hab das Global publish jetzt ertsmal drin gelassen, werde das dann raus nehmen wenn ich es verstanden habe ;(

DANKE

Beta-User

Also:
"globalPublish" und "mqttPublish" am einzelnen Device bewirken dasselbe, nur eben für einen anderen "Wirkungskreis". Hier hast du das zwar schon durch die devspec begrenzt (ausdrückliches Lob!) , aber trotzdem: Wenn du erst anfängst, kannst du es gefahrlos löschen und dann durch gezielte publishes ersetzen! Sonst läufst du ständig Gefahr, eine "Kleinigkeit" an der falschen Stelle zu ändern mit entsprechenden Auswirkungen...

Erst mal das, was an sinnvollen Änderungen am Client wäre:
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE
attr ha_MQTT2 subscriptions setByTheProgram

Das erste spart den Durchlauf durch MQTT2_DEVICE (das solltest du ggf. (hinten) ergänzen, falls (!) du "normale" MQTT-Geräte in FHEM haben willst/musst);
das zweite bewirkt, dass M2_CLIENT nur auf das hört, auf was den abbonierten Topics passiert (@all: das war bisher auch unter meinem Radar geflogen, kommt ins attrTemplate noch rein...).

Dann würde ich MGB so konfigurieren:
attr mqttGeneric globalDefaults pub:base={"fhem/$device"} sub:base={"fhem/set/$device"}
deleteattr mqttGeneric globalPublish

"retain" bewirkt teils seltsame Effekte, wenn FHEM oder der mosquitto neu gestartet werden (=> sollte nur aktivieren, wer weiß, was er tut!), und QOS ist bei "normalen TCP/IP-Verbindungen" sowieso durch features dieses Layers überlagert, wenn ich Rudi da richtig verstanden habe.
Damit hast du in Sende- und Empfangsrichtungen bei allen Geräten unterschiedliche Topics, und kannst dann dein eigentliches Gerät so konfigurieren:
attr wz mqttSubscribe state:stopic=$base
attr wz mqttPublish state:topic=$base
deleteattr wz mqttForward


Du musst dann halt noch checken, ob die subscription auf der Gegenseite dann noch dazu paßt.
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

hckoe

@Beta-User: Ist "$device" in den "globalDefaults xxx:base=" aktuell die Empfehlung. Im Thread über attrTemplate wurde das unterschiedlich diskutiert.   
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Beta-User

#54
Danke für den Hinweis, nein, ist es nicht (mehr) :o ...

Müßte dann also so aussehen
attr mqttGeneric globalDefaults pub:base=fhem sub:base=fhem/set
deleteattr mqttGeneric globalPublish

attr wz mqttSubscribe state:stopic={"$base/$device"}
attr wz mqttPublish state:topic={"$base/$device"}
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

jensorium

Hey

danke für die Inputs.

hier ist beides mal topic oder?
attr wz mqttSubscribe state:stopic=$base
attr wz mqttPublish state:topic=$base
deleteattr wz mqttForward

ändert aber nichts auch ohne S

ich fhem gibt keinen Output mehr und reagiert auch nicht auf die set befehle

probiert: hab in HA  geändert:
    command_topic: "fhem/set/wz"


daher hatte ich in deinem "sub:base={"fhem/set/$device"}"  das set nach hinten verschoben, ohne erfolg

Danke

Gruß

Beta-User

Da war mir beim editieren noch eine Klammer durchgerutscht, hoffe, das hattest du bemerkt:
attr mqttGeneric globalDefaults pub:base=fhem sub:base=fhem/set

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

jensorium

Hey

gesehen ja, gewundert, dachte aber es gehört so, Änderung brachte aber keinen Erfolg

hckoe

stopic für Subscribe-Topic ist schon richtig!
Wenn Du es nach Anleitung von Beta-User gemacht hast, müssest Du jetzt auf HA ein command-Topic: fhem/set/wz und ein state-Topic: fhem/wz definiert haben.
Auf FHEM-Seite ein Publish auf fhem/wz und ein Subscribe auf fhem/set/wz. Dann könntest Du mit mosquitto_sub ein subscribe auf diese beiden Topics machen und schauen, wie die Kommunikation jetzt verläuft, wenn Du auf beiden Seiten schaltest.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

gadget

#59
Mea culpa, ich sehe gerade, dass ich im Januar beim überarbeiten von Post #2 in diesem Thread einen sinn-entstellenden Fehler reingebaut habe bzgl. mqttForward. Hab es gerade nochmal überarbeitet. Das gehört natürlich zum dummy-device und nicht zur MGB. Das dürfte die Verwirrung in den letzten Posts erklären.