Menu
▾
▴
Re: [mh] MQTT Not Reliable
|
From: Giles Godart-B. <ggo...@gm...> - 2023-08-23 08:13:52
|
I've moved almost totally over to Tasmota devices because it supports
both http and MQTT and can be flashed to most devices that contain an
esp8266 chip.
For switches I use the native MH HTTP implementation because you get
immediate confirmation that it worked e.g. in Items.mht;
TASMOTA_HTTP_SWITCH, 192.168.100.81, Immersion_heater,
POWER1, Roof|Stay_off_when_out|Tasmota
I use MQTT for sensors, here are a few of examples; the broker is set up
in items.mht as follows;
MQTT_BROKER, mqtt_1
I have a Wemos D1 connected to a string of DS18B20 1-wire temperature
sensors that is defined in items.mht as follows;
MQTT_DEVICE, Roof_1_temperatures, MQTT_tempertures|Roof,
mqtt_1, tele/Roof_1_temperatures/SENSOR
Tasmota supports a huge number of devices, however some are not in the
supplied binaries, but are in their library, so you may need to do your
own build using their library code and a configuration file telling it
what modules to include. This is pretty easy if you use github, if
anyone wants more on this please email me. For example the MFRC522
RFID reader is one such device that is supported by their library but
not in the supplied binaries so once you have flashed Tasmota with your
build, it can be set up in MH items.mht as follows;
MQTT_DEVICE, Back_hall_RFID, Back_hall|tasmota_RFID, mqtt_1,
tele/Back_hall_RFID/SENSOR
The Tasmota Zigbee gateway is really useful to convert zigbee messages
to MQTT. You need to flash a device like the Sonoff Zigbee bridge with
Tasmota, then you can get these to interface with MH. The device is
defined in items.mht as follows;
MQTT_DEVICE, Back_hall_zigbee_gateway, Back_hall|zigbee_gateway ,
mqtt_1, tele/Back_hall_zigbee_gateway/SENSOR
CODE, $Back_hall_zigbee_gateway->{address} = "192.168.100.101";
CODE, $Back_hall_zigbee_gateway->{states_casesensitive} = 1;
Attached are a couple of screen grabs from the Zigbee gateway. Note the
records starting MQT: are the records it sends via MQTT.
There was an omission in the first release of the MH interface that did
not support wildcards which we fixed and I now believe is in the current
build. I make extensive use of the MQTT Last Will and Testament (LWT)
feature to detect when devices are powered up and when they die, for
this I use a wildcard for all LWT messages then decode the topic to find
the actual name of the device whose state changed. items.mht is defined
as follows;
MQTT_DEVICE, MQTT_LWT, , mqtt_1, tele/+/LWT
or for IP status messages
MQTT_DEVICE, MQTT_status5_handler, , mqtt_1, stat/+/STATUS5
Note that the MH MQTT handler messes with the case, if you want the case
of the messages to be unchanged when you get them in MH, add this line;
CODE, $MQTT_status5_handler->{states_casesensitive} = 1;
I hope this helps
Giles
p.s. Many years ago I met Andy Stanford-Clark who led the team at IBM
that developed MQTT, at the time I didn't get what he was so passionate
about, now I get it.
On 22/08/2023 21:30, mis...@si... wrote:
> I'll be diving into MQTT in the next month or two. From this
> discussion I gather that there is an MH-native MQTT implementation,
> and apparently another approach that Giles is using. I've seen
> https://github.com/hollie/misterhouse/wiki/Items-mqtt (though not yet
> studied it in-depth), but it doesn't apparently talk about what Giles
> is doing.
>
> Can someone please give me a very superficial explanation of the
> differences, or else point me to an article somewhere.
>
> Thanks in advance for any enlightenment.
>
> -Brian M
>
> On 8/22/23 11:08, Giles Godart-Brown wrote:
>> I also have a lot of MQTT devices using the native MH code with no
>> major issues.
>> Giles
>>
>> On 22/08/2023 17:50, H Plato wrote:
>>> On an unrelated note, is the insteon MQTT code more reliable than
>>> the native MH support? Why did you switch?
>>>
>>> I don’t have 120 devices, but probably 50 or so devices and it’s
>>> pretty good for reliability with the odd device exception. I have a
>>> challenge with some keypadlincs getting them to sync. the MH code
>>> seems to give up after a period of time, so I end up uninstalling
>>> the KPLs from the walls and into a temporary plastic electrical box
>>> that I can plug into the same outlet as the PLM.
>>>
>>> Dave if you submit a PR I can merge it in. There’s been a bunch of
>>> changes over the past year or so, might be good to capture a release
>>> soon. Unfortunately my git skills have atrophied so every time I
>>> think about doing this I get frustrated with some git situation and
>>> figure I’ll do it later….
>>>
>>>> On Aug 20, 2023, at 1:32 PM, Stephen Switzer <st...@sw...>
>>>> wrote:
>>>>
>>>> I'm probably running an old version of MH, so if this has been
>>>> fixed in the past 1-2 years, then please tell me to update. :)
>>>>
>>>> I created an integration that has MH listening to the mosquito
>>>> broker for some light commands, and for the most part, it's
>>>> working. However, it seems that random lights do not work when I
>>>> send a MQTT command to the broker. I can see the command hit the
>>>> broker, but it won't trigger an event in MH for all lights. I see
>>>> no difference between the lights that work and those that do not.
>>>>
>>>> Mosquito Broker:
>>>> insteon/living_room_lamp on
>>>> insteon/living_room_lamp/state on
>>>>
>>>> insteon/living_room_fan_light on
>>>> caddx/motion/binary_sensor.living_motion/state on
>>>> insteon/living_room_lamp off
>>>> caddx/motion/binary_sensor.living_motion/state off
>>>> insteon/living_room_lamp/state off
>>>>
>>>>
>>>> MH:
>>>> 08/20/23 03:21:57 PM [MQTT_RECV] living_room_lamp: on
>>>> 08/20/23 03:21:59 PM [LIGHTS] $ll_liv_lamp1 is 100%
>>>> 08/20/23 03:21:59 PM [MQTT_SEND] ll_liv_lamp1: on
>>>>
>>>> 08/20/23 03:22:06 PM [MQTT] MQTT_living_motion: on
>>>> 08/20/23 03:22:07 PM [MOTION] Motion sensed in Living.
>>>> 08/20/23 03:22:10 PM [MQTT_RECV] living_room_lamp: off
>>>> 08/20/23 03:22:12 PM [MQTT] MQTT_living_motion: off
>>>> 08/20/23 03:22:12 PM [LIGHTS] $ll_liv_lamp1 is off
>>>> 08/20/23 03:22:12 PM [MQTT_SEND] ll_liv_lamp1: off
>>>>
>>>> You can see MH is listening to the broker, sending messages
>>>> successfully, etc. The living_room_fan_light event was not picked
>>>> up from the broker by MH. I don't see why. Here's the code snippets:
>>>>
>>>>
>>>> $MQTT_insteon = new mqtt('mqtt_1', '127.0.0.1', 1883, 'insteon/#',
>>>> "", "", 120);
>>>>
>>>> $MQTT_insteon_living_room_fan_light_set = new
>>>> mqtt_Item($MQTT_insteon, "insteon/living_room_fan_light");
>>>> $MQTT_insteon_living_room_fan_light_state = new
>>>> mqtt_Item($MQTT_insteon, "insteon/living_room_fan_light/state", 1, 1);
>>>> if(my $state = state_changed $MQTT_insteon_living_room_fan_light_set) {
>>>> print_log("[MQTT_RECV] living_room_fan_light: $state");
>>>> set $living_room_fan_light $state;
>>>> }
>>>> if($state = state_now $fl_liv_fanlight) {
>>>> $state = ON if $state == '100%';
>>>> print_log("[MQTT_SEND] fl_liv_fanlight: $state");
>>>> set $MQTT_insteon_living_room_fan_light_state $state;
>>>> }
>>>>
>>>> $MQTT_insteon_living_room_lamp_set = new mqtt_Item($MQTT_insteon,
>>>> "insteon/living_room_lamp");
>>>> $MQTT_insteon_living_room_lamp_state = new mqtt_Item($MQTT_insteon,
>>>> "insteon/living_room_lamp/state", 1, 1);
>>>> if(my $state = state_changed $MQTT_insteon_living_room_lamp_set) {
>>>> print_log("[MQTT_RECV] living_room_lamp: $state");
>>>> set $living_room_lamp $state;
>>>> }
>>>> if($state = state_now $ll_liv_lamp1) {
>>>> $state = ON if $state == '100%';
>>>> print_log("[MQTT_SEND] ll_liv_lamp1: $state");
>>>> set $MQTT_insteon_living_room_lamp_state $state;
>>>> }
>>>>
>>>>
>>>> Mind you, I have about 120 lights in my code, all listening to
>>>> $MQTT_insteon. Could there be a memory issue? I appreciate any
>>>> input with ideas on this.
>>>>
>>>> Thank you!
>>>>
>>>> --
>>>> Best regards,
>>>> Steve Switzer
>>>>
>>>> ---
>>>> Get world-class business I.T. services and a phone system with awesome features that won't challenge your budget!
>>>> http://www.sbsROC.com <http://www.sbsroc.com/>
>>>> ________________________________________________________
>>>> To unsubscribe from this list, go to:
>>>> https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>>>
>>>
>>>
>>>
>>> ________________________________________________________
>>> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>>
>>
>>
>>
>> ________________________________________________________
>> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>
>
>
> ________________________________________________________
> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>
|
