MQTT Bugs / suggestions / improvements

[sjenkins]

*** LATEST BETA is 0.40.2
DONE README.md clean-up
DONE POLYGLOT_CONFIG.md clean-up
0.40.1
DONE:   S31 debug: displays in program now
0.40.0
DONE:   Changed versioning so git branches and hot fixes can work.
          so 0.40.0 means it will be on branch 0.40 with the last .0
          reserved for hotfixes.  These will then be pushed by PG3 to users
DONE raw fix docs & allow int in addition to str
DONE find topic by topic if no device_id find
DONE discover button updates nodes and MQTT subscriptions
DONE config.md fixes
DONE status for switch device available in programs
DONE internal: improve logging for debug
DONE:   Parameters are not initially populated, plugin uses the following defaults:
           mqtt_server = LocalHost
           mqtt_port = 1884
           mutt-user = admin (same as None)
           mqtt_password = admin (same as None)
DONE:   Switch make Status available in IF for programs

Please add your bugs, suggestions, and improvement thoughts in the forum thread 
I will update this list as ideas come in and are prioritized.

NEXT:   Query is not consistent across the devices

REMOVE:   iFan debug: ****calling this working (no changes made) as my tests work, also working for original raiser of issue. Let me know if not the case for anyone. 
HELP:    Google Assistant is not reporting device status consistently: 

Quote

 

I only access MQSwitch and MQDimmer with Google Assistant (Voice): when initially called on a hub or hub max, the screen shows the status as ON (and % for dimmer). And after a couple of seconds it reverts to OFF and 0%.

When using the Google Home app, you can click a device to turn it on and the GUI shows ON and stays on. But if I independently turn the light off locally, the GUI remains ON, meaning that it doesn't get feedback from the plug-in, or doesn't process it properly. AC does report when a light gets turned off locally.

 

HELP:   Multiple-Analog clean-up (particular issues?)
HELP:   Tasmota potential automation opportunities in discovery

LATER:  simplify devlist/devfile by using 'defaults' for status_topic and cmd_topic.

Quote

(They are mostly a combination of 'id' and a set of repetitive strings). This could reduce configuration pain by 80% and typos by 90%. Minimum need: 'id:' and 'type:' optional 'name:'

 

Edited May 9 by sjenkins
* updates for beta 0.40.2

[TriLife]

7 hours ago, sjenkins said:

As the title suggests, please add your bugs, suggestions, and improvement thoughts here. 
I will update this post as ideas make the list and are prioritized.

1. clean-up & fix docs
2. S31 debug
3. iFan debug
4. Switch make Status available in IF for programs
5. internal: improve logging for debug
6. make discover button also update Matt subscriptions
7. Query is not consistent across the devices
8. Tasmota potential automation opportunities in discovery
9. Multiple-Analog clean-up
10. ???

10- simplify devlist/devfile by using 'defaults' for status_topic and cmd_topic. (They are mostly a combination of 'id' and a set of repetitive strings). This could reduce configuration pain by 80% and typos by 90%. Minimum need: 'id:' and 'type:' optional 'name:'

11- Google Assistant is not reporting device status consistently: it shows correctly for a few seconds and then goes to 'OFF'

[maxnorth]

When MQTT server is first installed, it adds configuration keys by default: mqtt_server, mqtt_port, mutt-user, and mqtt_password. None of these is needed for a native eisy user.  Most users will not use a separate MQTT broker. So why add them? It creates confusion. Use configuration help instead to describe how to add them when/if needed.

It also add a "devfile" key by default with a suggestion as to where to store the file.  But do most users have the skills to create such a file and use terminal to store it on the eisy?  Perhaps use a devlist default instead OR add more extensive configuration help describing how to create the file and copy it to the eisy.

[maxnorth]

A config file glitch I noted previously:

BTW, I noticed an odd entry in the configuration help text:

""status_topic": For switch this will be the cmnd topic (like cmnd/sonoff1/power)"

I believe that should say "For switch this will be stat/sonoff1/POWER"

At least that's the way my devlist is structured.

[TriLife]

8 hours ago, maxnorth said:

When MQTT server is first installed, it adds configuration keys by default: mqtt_server, mqtt_port, mutt-user, and mqtt_password. None of these is needed for a native eisy user.  Most users will not use a separate MQTT broker. So why add them? It creates confusion. Use configuration help instead to describe how to add them when/if needed.

It also add a "devfile" key by default with a suggestion as to where to store the file.  But do most users have the skills to create such a file and use terminal to store it on the eisy?  Perhaps use a devlist default instead OR add more extensive configuration help describing how to create the file and copy it to the eisy.

You're absolutely correct @maxnorth. I put those defaults in when I was expanding the plugin a couple of years ago. Some of those fields are necessary on legacy setups (isy994, polisy, PG2, etc). With eISY and PG3x, they have become defaults.

I will ask UDI, how many users still are on legacy setups and we'll make adjustments as necessary.

Thanks for the feedback!

[maxnorth]

2 hours ago, TriLife said:

You're absolutely correct @maxnorth. I put those defaults in when I was expanding the plugin a couple of years ago. Some of those fields are necessary on legacy setups (isy994, polisy, PG2, etc). With eISY and PG3x, they have become defaults.

I will ask UDI, how many users still are on legacy setups and we'll make adjustments as necessary.

Thanks for the feedback!

The "not required" notes in the might suggest no VALUE is required to be entered in those default keys, where in fact the key can be deleted entirely. I ran the thing with blank keys for many months before I figured this out.

[sjenkins]

58 minutes ago, maxnorth said:

The "not required" notes in the might suggest no VALUE is required to be entered in those default keys, where in fact the key can be deleted entirely. I ran the thing with blank keys for many months before I figured this out.

You are right, we have added some ability to run with the default on user password and ip in the program where it assumes the default. This goes in the category of updating the docs to reflect that they are there for flexibility but can be omitted in default condition. 
Keep pointing these things out. @TriLife and I will knock them off over time. This plugin is very useful but it didn’t get any love for a while as well. Time to clean it up, and make some improvements!

(and not break it along the way. My plan is to put changes in beta for a couple of weeks for evaluation. Then move to production. This will give us wider testing than just @TriLife & I)

[sjenkins]

Take a look at the edits at the top of this thread & then install from the beta (non-production) store

The one you want is mqtt-poly. ** not mqtt

We are using the above beta as the alpha .... if that makes sense to you.

 

Give it a test and respond with feedback so we can move it forward.

[maxnorth]

On 4/25/2024 at 9:00 AM, sjenkins said:

As the title suggests, please add your bugs, suggestions, and improvement thoughts here. 
I will update this post as ideas make the list and are prioritized.

*** Putting up into Beta under MQTT-poly for the brave to try out and give feedback.

DONE:   Changed versioning so git branches and hot fixes can work.
          so 0.40.0 means it will be on branch 0.40 with the last .0
          reserved for hotfixes.  These will then be pushed by PG3 to users
DONE:   Switch make Status available in IF for programs
DONE:   Parameters are not initially populated, plugin uses the following defaults:
           mqtt_server = LocalHost
           mqtt_port = 1884
           mutt-user = admin (same as None)
           mqtt_password = admin (same as None)
DONE:   'raw' fix docs and allow to take int type in addition to str
DONE:discover button updates nodes and MQTT subscriptions

STARTED:CONFIG.MD, changed references of power to POWER. (please feel free to suggest other improvements to the docs)
STARTED:internal: improve logging for debug

NEXT:   Query is not consistent across the devices

HELP:   S31 debug:  ****need some specifics here of what is happening, logs aways help
HELP:   iFan debug: ****need some specifics here of what is happening, logs aways help
HELP:   Tasmota potential automation opportunities in discovery
HELP:   Multiple-Analog clean-up (particular issues?)
HELP:    Google Assistant is not reporting device status consistently: it shows correctly for a few seconds and then goes to 'OFF' (All / some devices?)

LATER:  simplify devlist/devfile by using 'defaults' for status_topic and cmd_topic. (They are mostly a combination of 'id' and a set of repetitive strings). This could reduce configuration pain by 80% and typos by 90%. Minimum need: 'id:' and 'type:' optional 'name:'
 

I can confirm that in v39 "status" is now showing as an option in programs for most devices.  An exception for me is s31. I will post separately about s31.

[maxnorth]

A follow up on the s31 issue.  Original details are in this thread: 

 

s31 energy monitoring updates (e.g., power factor, current power, total energy, etc.) ARE updating fine in the AC. There does not appear to be any issue with adding the device or keeping it up to date.

The issue is that the device is not available in Programs.  It is not visible in the "If" statement as a "control" or as "status". It IS visible in the "Action" statement, but with the only action available being "query" (as might be expected with a sensor).

I'm not sure that logs would be of any use here, but let me know what you'd like.

[sjenkins]

2 hours ago, maxnorth said:

A follow up on the s31 issue.  Original details are in this thread: 

 

s31 energy monitoring updates (e.g., power factor, current power, total energy, etc.) ARE updating fine in the AC. There does not appear to be any issue with adding the device or keeping it up to date.

The issue is that the device is not available in Programs.  It is not visible in the "If" statement as a "control" or as "status". It IS visible in the "Action" statement, but with the only action available being "query" (as might be expected with a sensor).

I'm not sure that logs would be of any use here, but let me know what you'd like.

@maxnorth  Pushed version 0.40.1 to non-production store  'mqtt-poly' not 'mqtt'

variables are available to programs now

 

 

[TriLife]

On 4/25/2024 at 11:00 AM, sjenkins said:

HELP:   Multiple-Analog clean-up (particular issues?)
HELP:    Google Assistant is not reporting device status consistently: it shows correctly for a few seconds and then goes to 'OFF' (All / some devices?)

I only access MQSwitch and MQDimmer with Google Assistant (Voice): when initially called on a hub or hub max, the screen shows the status as ON (and % for dimmer). And after a couple of seconds it reverts to OFF and 0%.

When using the Google Home app, you can click a device to turn it on and the GUI shows ON and stays on. But if I independently turn the light off locally, the GUI remains ON, meaning that it doesn't get feedback from the plug-in, or doesn't process it properly. AC does report when a light gets turned off locally.

Strong work on powering through all those items @sjenkins! Thanks so much

[maxnorth]

20 hours ago, sjenkins said:

@maxnorth  Pushed version 0.40.1 to non-production store  'mqtt-poly' not 'mqtt'

variables are available to programs now

 

 

Installed mqtt-poly, which shows as v40.2 as of this evening. My s31 device is still not visible in "status" for programs.

Also, installing using a different name (mqtt-poly) is not ideal, because there is no "reinstall" option.  This means you must delete your existing MQTT and then reinstall mqtt-poly in the same slot, if you wish to preserve your programs in AC. And you must reconfigure it in PG3. Then, you need to reverse this if you want to revert.

Having said that, I appreciate all of your efforts.  You need to get paid soon!

[maxnorth]

20 minutes ago, maxnorth said:

Installed mqtt-poly, which shows as v40.2 as of this evening. My s31 device is still not visible in "status" for programs.

Also, installing using a different name (mqtt-poly) is not ideal, because there is no "reinstall" option.  This means you must delete your existing MQTT and then reinstall mqtt-poly in the same slot, if you wish to preserve your programs in AC. And you must reconfigure it in PG3. Then, you need to reverse this if you want to revert.

Having said that, I appreciate all of your efforts.  You need to get paid soon!

Ok, on a second try, status has started to show up now!  Perhaps just rebooting the AC again is what was needed. Looks good.  I'll post again if I have any further problems with the s31. Here's an example of what's in my devfile:

 

- id: "sSonoffs31POW"
  type: "s31"
  name: "WaterHtrLoopEnergy_225"
  status_topic: "tele/sSonoffs31POW/SENSOR"
  cmd_topic: "cmnd/sSonoffs31POW/power"

[sjenkins]

1 hour ago, maxnorth said:

Ok, on a second try, status has started to show up now!  Perhaps just rebooting the AC again is what was needed. Looks good.  I'll post again if I have any further problems with the s31. Here's an example of what's in my devfile:

 

- id: "sSonoffs31POW"
  type: "s31"
  name: "WaterHtrLoopEnergy_225"
  status_topic: "tele/sSonoffs31POW/SENSOR"
  cmd_topic: "cmnd/sSonoffs31POW/power"

Good news; you had me for a moment. Took me a while to unwind that one. The editor profile file was messed up for s31. Anytime the profile files are changed restarting the AC needs to be done. 

Edited May 2 by sjenkins