MQTT crashes and restarts when topic received

[Timon]

Working now after the restart.

I'm using B1Trash's Simple Lines Icons. I really like them although I can think of a few additions. The biggest issue is that no one has done icons for Celsius as they don't quite scale right although for equipment temperatures they aren't bad.

I'll check out Jeff's just for fun.

[Michael McSharry]

There is much in this thread today and I do not totally follow, but there are a few things that I may be able to clear up. The area of graphics and subsequent editing of HS devices was modified in 3.4.19.x. This is available at http://mcsSprinklers.com/mcsMQTT_3_4_19_2.zip.
PR235 1/23/2019 3.4.19.0 VGP definitions are not changed after initial creation to protect subsequent user edits
PR236 1/28/2019 3.4.19.1 MISC edits on Edit tab are not reflected in HS devices if not done from the Edit popup

When one creates their own device or has a device created by another plugin then mcsMQTT does not have ability to affect the characteristics of the device. It is best to let mcsMQTT own devices that are associated with subscribed topics unless you happen to have another plugin for which a device can be controlled directly by a MQTT payload. For example, if you have a Zwave switch where CAPI control is On and Off and you want an external controller to directly control it and this controller has the ability to publish a payload of On and Off then you can associate the Ref of the Zwave device to the topic that this controller is publishing.

One issue did show up that I can't see how to fix. I can attach a graphic icon to the device. The topic that was subscribed to is temperature and I'd like to have the temperature graphic associated with device. I also want to use the graphic that change for each 10 degrees the temp changes. What I end of getting on the graphics page is this error "Device settings prevent editing/adding value/graphics pairs" How can this be fixed?

PR236 happens when you start with the Edit tab, but does not happen when you start from the Association tab and click the Ref button to bring up the Edit popup.
PR235 means that if you are going to make HS Device Management edits of mcsMQTT devices then you cannot go back and make edits on the Edit tab and expect what you have done in HS Device Management to be retained.

I then went to the Add/Edit tab and pasted in one of the topics. "auto/NUC8i3/Package id 0", and when it came up I set the reference field at the bottom for the device I want to contain that topic.

At that point the device does receive the published data but the plugin crashes.

Well, I got the crashing to stop. The only thing I did differently was to not set the reference to my pre made device and to go ahead and use the device it created. I don't understand why I can't set the device I want it to use but I can live with it this way although I hope this could be fixed.

Obvioiusly the crash should not occur and I will try to replicate here to understand what may be happening.

If I change the variable stuff then it doesn't work.

IE:

Currently the published command is this:

/GarageDoor1/cmnd/POWER

I have to send it an off for the button to work.

/GarageDoor1/cmnd/POWER Off

It doesn't do anything if I send:

/GarageDoor1/cmnd/POWER On

It is behaving the opposite way from intended.

I do not want the variable button to say off and everytime I change it it doesn't work anymore.

Note none of this debends the plugin.

If you trying to control mcsTasmota GarageDoor setup then the POWER command reflects the desired state of the garage door. If you send ON payload and the door is already in the On/Open state then nothing is expected to happen with the door. The reverse is also true of the Off/Closed state with an OFF command.

[quote]
You could also replicate (I think) the device over to WeatherXML and use Jeff's temperature graphics. This is less work than creating a per temperature graphic.
[/qutoe]
When defining a graphic for a mcsMQTT devices it does not matter what path is used as long as it is under /html of the HS folder. It is a pain to edit because HS always expects a specific subfolder as the starting point so if not there then it needs to be manually copied into the navigation box.

I use temperature icons from mcsSprinklers which were inherited from mcsTemperature back in the HS1 days. They can be obtained by unzipping a mcsSprinklers download and then putting them someplace convenient under the /html folder and best under a folder where HS defaults when entering them. mcsSprinklers is in the updater and can be downloaded at http://mcsSprinkilers.com/setup.zip

[Timon]

So from now own I'll make sure that I create devices from within mcsMQTT and since I know that normally it will set no graphics change that before I exit the initial creation.

If I understand correctly I'll still have to edit the graphics manually and that's fine. You really have no idea what the device actually is so you have no idea exactly what graphics would be needed.

I'll check out the graphics in mcsSprinklers and see if they would be useful but the Simple Line Icons are very nice.

From the crash point of view if you can duplicate it I'll try to write up the procedure in a little more detail.

Right now I'm mainly working with reading status from or controlling external devices and not having devices inside of HS3 controlled from external systems. That may change but not soon.

[Pete]

If you trying to control mcsTasmota GarageDoor setup then the POWER command reflects the desired state of the garage door. If you send ON payload and the door is already in the On/Open state then nothing is expected to happen with the door. The reverse is also true of the Off/Closed state with an OFF command.

Thank you Michael.

Yes I can only trigger the GDO open or close using the OFF command whatever state the garage door is in.

An ON payload doesn't do anything.

Confirmed this using the command line console in the Tasmota web gui.

Could that be related to the door switch configuration or the addition temperature sensor?

Should I switch GPIO3 to be Door Open and GPIO4 to be Door Closed (and swap sensor wires?)




Testing again...I understand this particular version of firmware was unique relating to the add of the DS18B20 sensor.

5.9.13g

Via Tasmota GUI toggled GDO open

14:22:34 HTP: Main Menu
14:22:36 MQT: /GarageDoor1/RESULT = {"POWER":"On"}
14:22:36 MQT: /GarageDoor1/POWER = On
14:22:37 MQT: /GarageDoor1/Door1 = INDETERMINATE
14:22:37 MQT: /GarageDoor1/Door1 = CLOSED
14:22:37 MQT: /GarageDoor1/Door1 = INDETERMINATE
14:22:37 MQT: /GarageDoor1/POWER = Off
14:22:39 HTP: Console
14:22:48 MQT: /GarageDoor1/Door1 = OPEN

Now sending an on power message while garage door is open.

14:24:11 CMD: GarageDoor1/cmnd/POWER ON
14:24:11 RSL: Group 0, Index 1, Command POWER, Data ON
14:24:11 MQT: /GarageDoor1/RESULT = {"POWER":"Off"}
14:24:11 MQT: /GarageDoor1/POWER = Off
14:24:11 MQT: /GarageDoor1/Door1 = OPEN

nothing happens

Now sending an off power message while garage door is open

14:24:37 CMD: GarageDoor1/cmnd/POWER OFF
14:24:37 RSL: Group 0, Index 1, Command POWER, Data OFF
14:24:37 MQT: /GarageDoor1/RESULT = {"POWER":"On"}
14:24:37 MQT: /GarageDoor1/POWER = On
14:24:38 MQT: /GarageDoor1/Door1 = INDETERMINATE
14:24:38 MQT: /GarageDoor1/POWER = Off
14:24:48 MQT: /GarageDoor1/Door1 = CLOSED
14:24:49 MQT: /GarageDoor1/Door1 = INDETERMINATE
14:24:49 MQT: /GarageDoor1/Door1 = CLOSED
14:25:07 MQT: /GarageDoor1/FAIL = {"Door1":"NOT CONFIRMED CLOSED"}

This closes the garage door but it does show a not confirmed closed message and a closed message.

Same thing when the garage door is shut.

IE: I can send a GarageDoor1/cmnd/POWER ON message and it does not open. If I send a GarageDoor1/cmnd/POWER OFF it opens the garage door.

Am I using the wrong command to toggle the relay?

/GarageDoor1/cmnd/POWER


xxx

[Michael McSharry]

Pete, it looks like the MQTT command changed between when I first implemented it and wrote the document. It was my first hack of Tasmota and I did butcher it and then as I added more things I tried to clean it up a little and made it more configurable. I could go back and fix it so it operates as the manual states, but likely will not because a workable solution exists. I don't know about the Console for the Door, but the following does work via MQTT, HS and Alexa. I used my subscribed DOOR topic as the one I mapped into HS and published on the topic GarageDoor/cmnd/Power with the publish template to publish the DeviceValue. Setup HS Device Management to give the button control/status as I did or just leave it for the defaults.

[Michael McSharry]

From the crash point of view if you can duplicate it I'll try to write up the procedure in a little more detail.

I tried various things with associating an existing HS device with a MQTT topic and never had any crash/cpu use issues. I did discover some things that I did not handle correctly in some cases. I fixed these in 3.4.20.1. http://mcsSprinklers.com/mcsMQTT_3_4_20_1.zip

While I do not think updates I made are related to crashing you experience, it would be good to pick up this version so the debug process has a know set of code. I will also need to know the steps you used to cause the crash. If it still occurs then I can add some selective debug on future builds to help isolate.

[Timon]

Michael,

Installed the updated to the new version, just copied the HSPI_MCSMQTT.exe file, and it seems to be working. I did noticed that the version didn't change. I assume that's because it was not released through either the normal or beta release or was setup using the local install file method.

As far as what I did when I started getting crashes it's as follows.

• Went to the Edit/Add tab.
• Copied the topic into the Sub field. At that point a new device reference showed up in the Ref: field and the green setup box appeared.
• Went to the bottom of the setup box and entered the Reference ID of the device I wanted it to control instead of the one was going to create and exited the page.
• From that point on any time that topic was published mcsMQTT would crash.

[Michael McSharry]

Issue appears to be caused by a status change of the non-plugin device that was associated in this manner. It results in publishing with a blank topic since no publish topic had yet been setup. The underlying library M2MMQTT.dll does not do a graceful error capture in this case. I fixed this in 3.4.20.2 by assigning a default publish topic when the association is made. http://mcsSprinklers.com/mcsMQTT_3_4_20_2.zip.

The version number should show up as 3.4.20.2. The prior one should be showing as 3.4.20.1.

[Pete]

looks like the MQTT command changed...

Thank you Michael; easy fix as I am only testing out 6 WiFi modded firmware devices. 3 1-Wire devices, 1 GDO device, 3 RGB devices.

Did a clean up of sorts yesterday...found that I had some 4000 MQTT lines saved from tinkering...so deleted everything here to start new for the 6 now used WiFi modded firmware devices...so down to around 700....reminds me of the xAP stuff...

This morning redid the GDO stuff and created two variables anyhow ....one purely for status and one as a button. Used the OPEN and CLOSED power command stuff. Works well this way.

Noticed when I used the $$VALUE it would send that out as a command for power versus OPEN or CLOSED. I was testing here while watching the stats coming out from mcsMQTT.

Using GarageDoor1/Door1/cmnd/POWER seems to work the best for me for control using OPEN and CLOSE.

When using /GarageDoor1/cmnd/POWER it would send out the OPEN and CLOSE to the Sonoff but it did not do anything which was odd as I did see the command going to the Sonoff.

Using the Tasmota documented console commands everything worked fine including using toggle which I tested for a bit but it was much easier to test watching the statistics (MQTT sniffer like) while concurrently sending out the published commands.

[Michael McSharry]

I suspect you have the MQTT topic setup to include prefix. My settings are shown in the attached.

[Pete]

Yes; similiar except here using GarageDoor1 and Door1. Everything is working fine now using the OPEN and CLOSE commands.

[Timon]

New version loaded. Version number in the plugin manager still shows 3.4.18.2 but then I don't think that HS pulls the version out of the file. Since I just copy the file over the old one HS never know that the version has changed.

Anyway, so I can now read the CPU temperatures from the Intel NUC8i3 that runs HS3 and several other services. Want to add some of the other temperatures on the NUC but that will take a little more work due to the way lm-sensors display them. After that I need to start putting together some sensors based on RaspberryPi Zero W for other things around the house.

[Michael McSharry]

Yes; similiar except here using GarageDoor1 and Door1. Everything is working fine now using the OPEN and CLOSE commands.

I have been using Tasmota Rules on some of my more recent project. It should be possible to implement most of the GDO logic in Rules and allow use of the current releases of Tasmota. The retry logic after specified wait period may not be possible in a rule, but that is not an essential part of it. In my case I am not going to change anything because it is working just as I want it to work.

[Pete]

Yeah it is working perfect now here too Michael. The only change here was using OPEN and CLOSE. My issue was editing the variable stuff then going to the reference number changes and wiping out the varable stuff every time I did this. This time started with the reference number variable change and tweaked the HS3 variable and all was fine.

All of the base Tasmota command line stuff did work via the console for the relay stuff....IE: power on, off, blink and toggle and status. The toggle function would be a one button thing for the HS3 variable stuff. It is not the same though very similiar to the MQTT command line stuff.

[Timon]

Well, I'm quite happy as I now have temperature monitoring working for my NUC8i3 including getting the drive temperatures.

All thanks to mcsMQTT, lm-sensors, hddtemp and the perl script "collect-sensor-data.pl" which formats and sends the data using MQTT.

I had to make some changes to the perl script so it worked the way I wanted to plus I need to add some filters to the sensors configuration file since several of the sensors all used temp1. Once that was changed then they had identifiable names.

Since the perl script didn't know how to get hard drive data I made a modified copy just for the drives.

Still needs some cleanup but I don't see why it would work for any Linux system that you can use sensors and hddtemp go get the data.

Currently I have a script I call inside of HS3 when runs the perl scripts. That way I can control how often I update it from HS3. At some point I'm likely going to let that run at the system level so it's independent of HS3.

I will say that it does seem a little strange getting the sensor data then sending it through MQTT to HS3 when they are all on the same system but it works.