Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

[hexenmeister]

Moin!
Was mir spontan einfällt: vlt. gibt es ein Problem mit dem Zeilenumbruch, ich meine ähnliches Problem hatte ich mit dem Bot (allerding in NodeRed).
Probiere mal so eine Nachricht direkt über Telegram-Device abzusetzen.
Bei der Bridge dürfte das eigentlich kein Problem sein (weder Größe noch Zeilenumbrüche), ich werde mal ausprobieren.

[Maui]

Direkt funktioniert es. Das hatte ich ja bis vor paar Wochen so als noch alles auf einem Fhem System lief.
Aber ich teste es nochmal. Es kommt ja gar nicht beim Ziel System an die Nachricht bzw. Wird gar nicht an den mosquitto gesendet.

[hexenmeister]

Ok, muss ich nachsehen, möglicherweise geht die Nachricht auch im MQTT-Modul kaputt. Benutzt Du MQTT oder MQTT_CLIENT/SERVER?

[Maui]

Als Modul MQTT und als Server mosquitto

[Maui]

Ich habe grad mal noch ein wenig am Host geguckt.
Auch mit verbose 5 kommt bei der GB scheinbar nix an.
Einfache Meldungen gehen problemlos

Code Auswählen Erweitern


2019.06.05 19:11:25 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGB] publish: fhem/telebot/message => hallo (qos: 0, retain: 0)


Und auch wenn ich den Text nehme, den er rüber schicken soll und händisch kopiere und per set nochmal einfüge an das Reading klappt es auch.
Es kann also eigentlich nur die Leerzeile am Beginn sein oder andere nervige Steuerzeichen.

[hexenmeister]

Kannst Du mal den genauen Text üpost, was Du verwendest hast? Bei mir gehen Zeilenumbbrüche etc. problemlos in einem Dummy in Reasings rein.

[hexenmeister]

Das weiß ich (noch) nicht. Werde versuchen rauszufinden. Generell sind ja Events da, nur an die Bridge kommt nichts an. Vermutlich sehe ich gerade den Wald vor lauter Bäumen nicht.

Entgegen meiner ersten Vermutung, kommen Events doch bi er Bridge an. Aaaber...
... es funktioniert eben nicht mit 'state'. Ich verwende in der Bridge Schleife für die Events eines Gerätes:

Code Auswählen Erweitern

foreach my $event (@{deviceEvents($dev,1)}) {
...
}

Zweites Argument in deviceEvents bedeutet, dass auch 'state' als z.B. 'state: off' ausgegeben werden soll. Das nimmt die Routine aus dem Device-Hash aus $hash->{CHANGEDWITHSTATE}. Und dieser ist bei dem Update über die readingsProxy eben nicht da, nur $hash->{CHANGED}:

{
          'INTRIGGER' => 1,
          'CONTENT' => {
                         'MCP23017' => 1
                       },
          'NTFY_TRIGGERTIME' => '2019-06-05 23:36:08',
          'INSET' => 1,
          'READING' => 'PortB7',
          'NOTIFYDEV' => 'global,MCP23017',
          'CHANGED' => [
                         'off'
                       ],
          'NTFY_ORDER' => '50-GaragePflanzenlampe',
          '.attrminint' => [],
          'FUUID' => '5cf6dbc3-f33f-447f-992a-3bb0ff1e7da3b0e8',
          'TYPE' => 'readingsProxy',
          'READINGS' => {
                          'state' => {
                                       'VAL' => 'off',
                                       'TIME' => '2019-06-05 23:36:08'
                                     },
                          'lastCmd' => {
                                         'TIME' => '2019-06-05 23:36:08',
                                         'VAL' => 'off'
                                       }
                        },
          'DEF' => 'MCP23017:PortB7',
          'NR' => 21030,
          'NAME' => 'GaragePflanzenlampe',
          '.triggerUsed' => 1,
          'DEVICE' => 'MCP23017',
          'STATE' => 'off',
          '.attraggr' => [],
          'CFGFN' => ''
        };

Zum Vergleich wie es aussieht, wenn GenericBridge state direkt an einem Dummy setzt:

2019.06.05 23:51:37 1: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] Notify for MCP23017X event: state: off STATE: off $VAR1 = {
          'NTFY_TRIGGERTIME' => '2019-06-05 23:51:37',
          'NR' => 21211,
          'TYPE' => 'dummy',
          'READINGS' => {
                          'state' => {
                                       'VAL' => 'off',
                                       'TIME' => '2019-06-05 23:51:37'
                                     }
                        },
          'FUUID' => '5cf6dde5-f33f-447f-bc26-8019992311b5c145',
          'INTRIGGER' => 1,
          'STATE' => 'off',
          '.attraggr' => [],
          'CFGFN' => '',
          'CHANGEDWITHSTATE' => [
                                  'state: off'
                                ],
          '.attrminint' => [],
          'CHANGED' => [
                         'off'
                       ],
          '.triggerUsed' => 1,
          'NAME' => 'MCP23017X'
        };

Keine Ahnung, warum das bei readingsProxy so ist. Ich überlege mir, wie ich das sauber und nebenwirkungsfrei in der GenericBridge erkennen kann...

[hexenmeister]

Probiere mal die angehängte Version. Bei mir funktioniert diese in deinem Fall. Ich hoffe, es gibt dabei keine Nebenwirkungen.

[Dersch]

Auf den ersten Blick sieht es gut aus!!! ich teste und beobachte mal

Vielen Dank für deine Mühe

[hexenmeister]

Ich habe grad mal noch ein wenig am Host geguckt.
Auch mit verbose 5 kommt bei der GB scheinbar nix an.
Einfache Meldungen gehen problemlos

Code Auswählen Erweitern


2019.06.05 19:11:25 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGB] publish: fhem/telebot/message => hallo (qos: 0, retain: 0)


Und auch wenn ich den Text nehme, den er rüber schicken soll und händisch kopiere und per set nochmal einfüge an das Reading klappt es auch.
Es kann also eigentlich nur die Leerzeile am Beginn sein oder andere nervige Steuerzeichen.

Ich glaube, das Problem ist in der Bridge. Aber nicht beim Empfang, sondern beim Senden. Es funktioniert irgendwie nicht, Nachrichten mit Zeilenumbrüchen zu versenden. Heute ist aber schon zu spät zum weitersuchen.

[Maui]

Ich glaube, das Problem ist in der Bridge. Aber nicht beim Empfang, sondern beim Senden. Es funktioniert irgendwie nicht, Nachrichten mit Zeilenumbrüchen zu versenden. Heute ist aber schon zu spät zum weitersuchen.

Guten Morgen. Auch wenn du es wohl schon gefunden hast, hier nochmal 2 Screens.
1. wird erstellt und nicht gesendet, 2. geht problemlos durch die Bridge.

[Dersch]

Probiere mal die angehängte Version. Bei mir funktioniert diese in deinem Fall. Ich hoffe, es gibt dabei keine Nebenwirkungen.

Also bisher kann ich keine ungewollten Nebenwirkungen feststellen.

[hexenmeister]

Jetzt eine Testversion für mehrzeilige Texte, bitte ausprobieren.

[Maui]

Jetzt eine Testversion für mehrzeilige Texte, bitte ausprobieren.

Erster Test sieht gut aus. Morgen teste ich weiter. Zu spät. Danke schonmal.

Gruß Maui

[hexenmeister]

Habe die nue Version jetzt eingecheckt.

Eine Unschönheit hat das readingsProxy-Patch schon. Da Die Bridge nicht explizit mitgeteilt bekommt, dass es sich in diesem Fall um 'state' handelt, versucht sie das selbst zu erkennen. Die Erkennung wird fehlschlagen, wenn man versucht, über die Bridge an ein readingsProxy-Gerät für 'state' ein Wert (eine Zeichenkette) mit mindestens einem Doppelpunkt und unmittelbar folgendem Leerzeichen zu senden. Die Bridge wird das Teil vor dem Doppelpunkt fälscherweise als Readingsnamen annehmen. Sicher könnte man diese Heuristik etwas schlauer machen, ich denke jedoch, das Problem liegt an dem Zusammenspiel zw. readingsProxy-Modul und dem FHEM selbst. Dort sollte man auch nach einer generellen Lösung suchen.