Help me with a Smart Home Interview – US Participants Needed

[Elcid]

Is @christian_fabre bridged to mosquitto? As when I reload OpenLuup I have to restart mosquitto to get them talking again.

[christian_fabre]

[therealdb]

@akbooer I will probably add more log, to see the exact payload sent. Sometimes those things are generating strange telemetry data, so maybe that's the case. I'll probably log what's going on around hadevice property as well. I was unable to re-produce it in my own install, so it should be something related to this particular model and its messages.

[akbooer]

@christian_fabre

If you are still interested, testing v21.5.3 is available. I have made considerable changes.

[christian_fabre]

I just installed the testing version 21.5.3.
It works great for Shelly but also for Tasmota

Merci bien

[akbooer]

@christian_fabre said in MQTT – setup and use:

Merci bien

Je vous en pris.

Believe me... I'm happy. So sorry for all the mis-steps, but I learned a few things along the way, so it was a worthwhile exercise!

[rafale77]

@akbooer

Now that you got that figured out, one awesome thing which could be done would be integrate this:

GitHub - Koenkk/zigbee2mqtt: Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨 - Koenkk/zigbee2mqtt

By creating a bridge supporting it on openLuup. It would enable me to move zigbee from home assistant to run directly to openLuup and I would likely take advantage of it to get rid of my hue hub as well, running a single zigbee network through mqtt...

[therealdb]

@rafale77 its topics are pretty organized, so it should be easy to do. The only difficult part is to get a reliable trace of messages, so an emulator could be written to facilitate development and testing.

[akbooer]

@buxton said in MQTT – setup and use:

As near as I can tell, if openLuup tries to connect to a running mosquitto instance, then it fails to see the topics and messages, and passes empty--but not nil--strings when the servlet interface sees incoming bytes.

OK, I’m ready to take a look at this. However the above statement makes no sense to me, since the server never connects to anything (because it’s a server – clients connect to it.)

[Buxton]

@akbooer Yes, that was poorly worded as it makes it sound like openLuup initiates the connection to Mosquitto.

The symptoms of the problem are that:

• if luup reloads, an occasional message that is sent to openLuup from Mosquitto causes a receive error in openLuup. It is unknown what that/those message(s) are.
• if mosquitto reloads, the openLuup error messages stop, so something changes in the way that openLuup sees the mosquitto data.
• this behavior does not occur with IOT devices.

A possible way to trouble shoot this is to place debug code at the incoming interface that will trap and display packets headed to the MQTT port. By comparing incoming timestamps with the error message timestamp, I should be able to tell what message is causing the receive error message--even though the message variable is empty at the time it causes the luup error. What is odd to me is that there is a lot of error trapping for bad messages in your code, but this message(s) seems to bypass all of that and arrives at the incoming routine empty.....

[akbooer]

I think we are being misled by your error messages. These tables are not empty...

local x = {a = 1, b = 2}
local y = table.concat (x)
print (y == '')

yields the expected result true.

[Buxton]

Ah! Yes that explains the empty variable, though I'm going to have to dig into my lua book to understand why! I was assuming that the concat function returned a series of string values from a table, and therefore, the output could be sent to the log for display.

[akbooer]

It works only for a contiguous array of numbers and/or strings...

local x = {"a ", 1, " b ", 2}
local y = table.concat (x)
print(y)

gives

a 1 b 2

[Buxton]

@akbooer Ok, so the variable "message " contains more than just a value array.

I've never been able to get zerobrane as a debugger working with openLuup, though the instructions on how to do so have been written about previously. I just couldn't get the debugger working on a target remote PC, so it's difficult to watch what's going on within the myriad method code in the object model you've created. I don't write code for a living--never have-- though I use SQL, VBA and Python in my day to day job. The debuggers for those languages are a breeze compared to setting up zerobrane and Vera.....

[akbooer]

Yes, the message structure is an object with various values and methods:

      {
        -- variables
        length          = nb,             -- byte count for statistics
        packet_type     = packet_type,
        control_flags   = control_flags,
        body            = body,           -- may include variable header and payload
        ptr             = 0,              -- pointer to parse position in body
        packet_name     = pname,          -- string name of packet type
        -- methods
        read_bytes      = read_bytes,
        read_flag_byte  = read_flag_byte, -- converting octet to 8 separate flag bits
        read_word       = read_word,
        read_string     = read_utf8,
      }

It's that way, because MQTT message formats are dependent on the type of message, so the methods contain here do some of that job. However, for the publish / subscribe functions, the topic and message parameters are simple strings, so easy to print out.

As for debugging, I run the entire openLuup system within ZeroBrane during development, so most things are directly traceable and the debugging facilities are very adequate. I've never, ever, tried to debug a remote system.

Still keen to discover the cause of your bridged server issue...

...have you tried enabling DEBUG of the MQTT module itself? It provides some useful information.

[Buxton]

@akbooer Yeah, I've tried debug and there's nothing in the log that helps.

If you ever do get the notion to connect to a remote instance, let me know the steps as the procedure that was outlined on the vera forum was fairly complex.

[akbooer]

@archers said in MQTT – setup and use:

I found a post on the Shelly forum that said that there in some cases (or for some devices) could be a problem with the latest Shelly firmware and Mqtt.

Do we know if this issue has been solved yet?

I’ll update all my device firmware if so, but I’m loathe to do so without some sort of confirmation. TIA.

[ArcherS]

@akbooer I have not upgraded any of mine so I do not know.

This thread and the post from May 14th indicate some Mqtt changes in 1.10.5_RC1. And this thread indicates that 1.10.4 may still have had some problems.

Maybe someone else here has tested?

[ArcherS]

@akbooer today I set up a new Shelly Plug.

The firmware on it was quite old and I thought I would give the latest release a go and see if the Mqtt problem was solved. I loaded "v1.11.4-DNSfix" on the plug and then set up Mqtt as per my other Shellies, then - nothing. It did not show up in Mqtt Explorer at all.

I then downgraded to v1.9.4 on the plug and it immediately showed up as it should.

I did not dive down into the problem more, I will however stay away from the latest releases for the time being. On my devices v1.9.x does the job and Mqtt works.

As a side note I also set up a Shelly Flood that will live under the dishwasher and it seems to work pretty good. The Shelly battery devices are a bit of a pain to set up but I got it to work eventually. I have since before a Button1 that was painfully slow on battery; I run it on USB and then it is ok.
After having set up the flood sensor I tested it and it gave an alert as it should only after a few seconds delay.

[akbooer]

Thanks for the update! I’ve reverted to to a "if it ain’t broke, don’t fix it" approach myself, so haven’t been upgrading the Shelly firmware.