[Solved]Bug in 10_MQTT_GENERIC_BRIDGE

[chanky]

Dear modul maintainer,

I would like to report a bug in the module 10_MQTT_GENERIC_BRIDGE.

I'm using the bridge to route my incoming and outgoing mqtt messages using diverse devices as you can see below. 
Under my definition i have for instance -> 'TYPE=dummy'  so today i added a new dummy device and i expected the mqtt extensions (mqttPublish, mqttSubscribe, etc) to pop under the attributes since the bridge in its definition contains TYPE=DUMMY. Unfortunately this was not the case, i did a shutdown restart and still the attribute were still missing.

My expection here are that, when a new device is added and the device is defined as a mqtt device, in my case (bedRoomLamp, TYPE=dummy, TYPE=Weather, garbage) the device created should have automatically the mqtt attribute extensions.

Code Auswählen Erweitern


Internals:
   DEF        mqtt bedRoomLamp, TYPE=dummy, TYPE=Weather, garbage
   FUUID      5c457db9-f33f-ccf0-7b4e-fea59171180a2a45
   IODev      MQTT_Broker
   NAME       mqttGeneric
   NR         104
   NTFY_ORDER 50-mqttGeneric
   STATE      ???
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    bedRoomLamp,TYPE=dummy,TYPE=Weather,garbage
   prefix     mqtt
   CHANGED:
     incoming-count: 131
     incoming-count: 132
     incoming-count: 133
     incoming-count: 134
     incoming-count: 135
     incoming-count: 136
     incoming-count: 137
     incoming-count: 138
     incoming-count: 139
   READINGS:
     2019-01-30 18:58:25   device-count    13
     2019-01-30 19:04:00   incoming-count  139
     2019-01-30 19:04:00   outgoing-count  135
     2019-01-30 19:04:00   transmission-state outgoing publish sent
     2019-01-30 18:58:24   updated-reading-count 0
     2019-01-30 18:58:25   updated-set-count 4
   devices:


[hexenmeister]

The definition is wrong. The bridge uses internal function (devspec2array). This expects the device definition WITHOUT spaces.

To try for yourself:

Code Auswählen Erweitern

{use Data :: Dumper ;; Dumper (devspec2array ('bedRoomLamp, TYPE = dummy, TYPE = Weather, garbage'))}
does not deliver anything

Code Auswählen Erweitern

use Data :: Dumper ;; Dumpers (devspec2array ('bedRoomLamp, TYPE = dummy, TYPE = Weather, garbage'))}
This will deliver the desired result.

I recommend reading the fhem basics again.

[chanky]

Additional infos:
Please find two screenshots one with a dummy showing the mqtt attributes and another without the attributes

Fhem version

Code Auswählen Erweitern


Latest Revision: 18452

File                      Rev   Last Change

fhem.pl                   18423 2019-01-26 16:17:38Z rudolfkoenig
96_allowed.pm             17613 2018-10-24 15:37:39Z rudolfkoenig
90_at.pm                  17561 2018-10-18 14:45:30Z rudolfkoenig
98_autocreate.pm          18091 2018-12-30 09:57:04Z rudolfkoenig
00_CUL.pm                 17559 2018-10-18 07:45:07Z rudolfkoenig
95_Dashboard.pm           16920 2018-06-29 12:01:56Z DS_Starter
98_dummy.pm               16965 2018-07-09 07:59:58Z rudolfkoenig
91_eventTypes.pm          14888 2017-08-13 12:07:12Z rudolfkoenig
98_fheminfo.pm            18323 2019-01-18 19:37:39Z betateilchen
01_FHEMWEB.pm             18383 2019-01-22 18:45:50Z rudolfkoenig
11_FHT8V.pm               14888 2017-08-13 12:07:12Z rudolfkoenig
92_FileLog.pm             18224 2019-01-12 18:48:47Z rudolfkoenig
10_FS20.pm                14888 2017-08-13 12:07:12Z rudolfkoenig
98_help.pm                18341 2019-01-19 17:24:30Z betateilchen
95_holiday.pm             18112 2019-01-01 14:52:36Z rudolfkoenig
02_HTTPSRV.pm             16874 2018-06-15 17:18:55Z neubert
10_IT.pm                  18090 2018-12-30 07:24:59Z bjoernh
00_MQTT.pm                17362 2018-09-17 12:57:29Z hexenmeister
00_MQTT2_CLIENT.pm        18440 2019-01-28 10:23:20Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 18450 2019-01-29 21:47:53Z hexenmeister
No Id found for 99_myUtils.pm
91_notify.pm              17225 2018-08-29 12:34:29Z rudolfkoenig
98_PID20.pm               10722 2016-02-04 17:12:18Z john99sr
33_readingsGroup.pm       16299 2018-03-01 08:06:55Z justme1968
98_structure.pm           18182 2019-01-08 18:34:06Z rudolfkoenig
99_SUNRISE_EL.pm          18303 2019-01-17 19:47:40Z rudolfkoenig
98_SVG.pm                 17779 2018-11-18 17:49:14Z rudolfkoenig
98_telnet.pm              17529 2018-10-14 12:57:06Z rudolfkoenig
98_update.pm              18431 2019-01-27 12:37:02Z rudolfkoenig
99_Utils.pm               15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm             15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm             18386 2019-01-23 06:43:45Z CoolTux
98_weblink.pm             16293 2018-02-28 21:33:57Z rudolfkoenig

AttrTemplate.pm           17973 2018-12-14 18:19:05Z rudolfkoenig
Blocking.pm               17553 2018-10-17 15:56:35Z rudolfkoenig
No Id found for ConnAck.pm
No Id found for Connect.pm
No Id found for Constants.pm
DevIo.pm                  17994 2018-12-17 14:32:10Z rudolfkoenig
No Id found for Disconnect.pm
GPUtils.pm                 6653 2014-10-02 11:59:37Z ntruchsess
HttpUtils.pm              17831 2018-11-24 15:09:17Z rudolfkoenig
No Id found for JustMessageId.pm
No Id found for Message.pm
myUtilsTemplate.pm         7570 2015-01-14 18:31:44Z rudolfkoenig
myUtilsTemplate.pm         7570 2015-01-14 18:31:44Z rudolfkoenig
OpenWeatherMapAPI.pm      18306 2019-01-17 21:25:55Z CoolTux
No Id found for PingReq.pm
No Id found for PingResp.pm
No Id found for PubAck.pm
No Id found for PubComp.pm
No Id found for Publish.pm
No Id found for PubRec.pm
No Id found for PubRel.pm
RTypes.pm                 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm          18197 2019-01-09 20:50:34Z rudolfkoenig
No Id found for SubAck.pm
No Id found for Subscribe.pm
TcpServerUtils.pm         17529 2018-10-14 12:57:06Z rudolfkoenig
No Id found for UnsubAck.pm
No Id found for Unsubscribe.pm

fhemweb.js                 18399 2019-01-24 13:18:20Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     18357 2019-01-20 19:05:41Z rudolfkoenig


Best regards
Chanky

[hexenmeister]

ok, I'll take a look at that a little bit later

[chanky]

Sorry mate,

I did read the basics pretty well
Anyway in both your examples you posted identical code apart from the '{' you left out in the second one.

I did try it out with the spacing and well the new device  got now the correct attributes but i went ahead and added a new dummy one and again the attributes were missing, it seems the attributes get updated overall ONLY if mqttGeneric device is modified.

See new screenshots

Code Auswählen Erweitern


Internals:
   DEF        mqtt bedRoomLamp,TYPE=dummy,TYPE=Weather,garbage
   FUUID      5c457db9-f33f-ccf0-7b4e-fea59171180a2a45
   IODev      MQTT_Broker
   NAME       mqttGeneric
   NR         104
   NTFY_ORDER 50-mqttGeneric
   STATE      ???
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    bedRoomLamp,TYPE=dummy,TYPE=Weather,garbage
   prefix     mqtt
   CHANGED:
     incoming-count: 1512
     incoming-count: 1513
     incoming-count: 1514
     incoming-count: 1515
   READINGS:
     2019-01-30 20:02:17   device-count    13
     2019-01-30 20:09:35   incoming-count  1515
     2019-01-30 20:09:35   outgoing-count  1504
     2019-01-30 20:09:35   transmission-state outgoing publish sent
     2019-01-30 20:02:17   updated-reading-count 0
     2019-01-30 20:02:17   updated-set-count 8
   devices:

The definition is wrong. The bridge uses internal function (devspec2array). This expects the device definition WITHOUT spaces.

To try for yourself:

Code Auswählen Erweitern

{use Data :: Dumper ;; Dumper (devspec2array ('bedRoomLamp, TYPE = dummy, TYPE = Weather, garbage'))}
does not deliver anything

Code Auswählen Erweitern

use Data :: Dumper ;; Dumpers (devspec2array ('bedRoomLamp, TYPE = dummy, TYPE = Weather, garbage'))}
This will deliver the desired result.

I recommend reading the fhem basics again.

[hexenmeister]

OK, you're right. The spaces are unimportant here. Sorry.

Still, I can not reproduce the bug.
The userattr are created cleanly for all devices and also deleted when changing the bridge definition.

As a workaround you can use default definition (without specifying the devices). Or try to create userattr yourself.

[chanky]

The problem is the other way round.

If a device from an existing family is added  (lets say you have TYPE=dummy in the definition). The extended attributes are only appended to the device ONLY after any of the attibutes belonging to the bridge are changed. If the bridge remains intact the attributes are NOT appended automatically to the new device.

Workaround: Inorder for the attributes to appear on the new device one has to modify slightly the bridge. Then this triggers the setting of the extended attributes to the whole device family defined in the definition
Best regards
Chanky

Sent from my SM-G930F using Tapatalk

[hexenmeister]

I implemented new feature today: "get refreshUserAttr". Renewed user-artr attributes. Update tomorrow.

Or just restart your fhem

[chanky]

"get refreshUserAttr" works like a charm 

see attachment:

I implemented new feature today: "get refreshUserAttr". Renewed user-artr attributes. Update tomorrow.

Or just restart your fhem