temp probes changing identity

I've been trying to figure what's happening to my solar hot water system, and have realised that two of my temperature probes have swapped identity, which is kind of a relief though not very convenient..

i suspect this has nothing to do with Indigo or the plugin and that for some reason the Shelly has re-ordered their IDs (though I didn't keep a record of the native probe number), but curious if anyone else has experienced this (or thought of a work-around). The event coincided with coming out of a wifi and power outage, however the devices were not reconfigured.

[out of interest, here's the chart - the brown upper tank line suddenly started reporting lounge temperature].

Very interesting . The MQTT API exposes some topics for temperature "channels", but they don't explicitly say how a sensor is tied to a channel. The one-wire temperature probes have a hardcoded serial number, but I don't believe there is a way to target a specific sensor by its identifier. I guess the Shelly device swapped which sensors correspond to the different sensor channels.

The correction this is just to swap the channel selection on the two devices representing those sensors. I will have to look into whether the Shelly devices publish the sensor identifiers anywhere.

yeah I was able to recover just by swapping channels. I suspect this has happened before with other Shelly devices, but at the time I put it down to incorrect configuration as I didn't have a chart set up to visualise the historic shift. Shuffling of channels also happens (which is more reasonable, though still a bit lazy on Shelly's part as they could at least follow numeric priority or suchlike) on a factory reset.

I took a look at the incoming data and it does look like the sensor identifier is passed through for each channel as 'hwID'. Here's what MQTT Explorer reports for a Shelly with two probes attached (there's an Imperial and metric version of the same sequence]

Code: Select all

{
  "0": {
    "hwID": "2885186e38190123",
    "tF": 127.5
  },
  "1": {
    "hwID": "0000000000000000",
    "tF": 999
  },
  "2": {
    "hwID": "2893124238190115",
    "tF": 86.1

Maybe exposing the hwID as a property would at least allow unexpected changes to be monitored? I guess it would also be possible to provide an option to use hwID as they key for creating the child device, rather than channel number... but thats probably overkill for a (hopefully) rare event.

Can you provide the topic where that data is located? (And a full message as an example?)

I believe it would be straightforward to extract the sensor identifier and include it in the states list for a device, but I am hesitant to make the identifier the "key" for choosing a sensor. Like you said, this seems like a rare event and, in my opinion, this sounds like a Shelly firmware bug.

Idea: allow you to still choose Channel 1-3 for a sensor, and create a simple menu item to display the sensor identifiers that are connected to a given device. In the sensor add-on devices there would be a textfield that would be optional. You could enter your sensor identifier as an additional check where the plugin will ensure that the identifier matches the sensor on the channel. In the event that a sensor has swapped channels and the identifiers no longer match, the sensor value could be rejected and begin logging errors to notify you.

This results in no changes for existing devices, adds no complexity for users only utilizing one sensor at a time, and doesn't force people to need to care about sensor identifiers if they don't want to.

That does sound like a very workable solution.

Even without the apparent bug, one thing I do find a pain with Shellys is some have a tendency to be reset by accident (mainly those with a light switch attached) so this would be handy also in that scenario.

the topic:

Code: Select all

shellies/shelly1-500291F0E4B1-solar1/ext_temperatures

has this payload:

Code: Select all

{"1":{"hwID":"28d24a37381901d5","tC":16.9},"0":{"hwID":"2885186e38190123","tC":46.6},"2":{"hwID":"2893124238190115","tC":25.4}}

(the content is duplicated - but with temperatures in farenheight - in the Imperial Measurement version of the topic:

Code: Select all

shellies/shelly1-500291F0E4B1-solar1/ext_temperatures_f

note there's another pair of topics 'ext_temperature' [singular] that provides the temps but not the hwIDs.

Thanks for that. I have the sensor device reading from the single value topics (/ext_temperature/[0-2]), and the selected channel determines which topic a device reads from.

I have actually come up with a way to choose a sensor either by channel or by a sensor identifier. I will let you know when I have a version ready that should solve your problem.

I don't have a lot of experience with multiple sensors on a single Shelly, so that could be why I never noticed this issue. And when I did test with multiple sensors, they were right next to each other and reporting the same values...

exactly -if they were reading something like temperatures for adjacent rooms it would be easy to miss the shuffle! It's silly the probes don't have a predictable order.

thanks for your help!

I have been working on v0.5.0 which has this enhancement implemented. I don't have it released yet, but it is available on the 0.5.0 branch. Would you mind trying this new version? I designed the changes in such a way that updating the plugin should have no effect on existing sensors that were configured using the channel selection.

Would you mind checking that all of your sensors continue to function correctly after the update (and plugin restart) and BEFORE opening any of their configuration windows?

The channel selection menu for each device will now include the hardware identifiers to target if so desired. I believe I have everything processing correctly, but a DS1820 add-on will only show identifiers that are DS1820 devices (the same logic holds for DHT22 sensors). There is also a new plugin menu item called "Log Connected Sensors..." which allows you to select a device and all connected sensors are printed to the log.

The only unknown I have at the moment is the frequency at which the /ext_* topic is published. The plugin devices monitor these topics to extract the known hardware identifiers connected to it. So, if the topic hasn't been published between the time the plugin/device is first started and when configuring a device, then the dropdown menu will not show any hardware identifiers. I believe this topic is updated at the same frequency as the sensor updates, but I'm not sure.

If no hardware identifiers are shown, then one thing to try is performing a "Send Status Request" from the Indigo UI on the host device. That has the same effect as forcing the device to announce, and that might force the device to update the /ext_* topics as well.

Thanks,
Aaron

Brilliant!

The probes continued to work without config, and 2 of the 3 Shellies i'm using with temp probes showed the hardware ID listings more or less immediately. One was recalcitrant, and after 5 minutes I tried the status request, still to no avail - however a device reboot of the Shelly fixed things and it seems to be working perfectly. (I'll keep watch overnight.)

The only tweak I can think of which would improve usability would be to display the current correlation between probe number and hardware ID (its not in the Shelly UI that iI can find, so it requires something like MQTT explorer to figure which hwID relates to which probe number (assuming you cant deduce it from the temp reported).

cheers
adam.

Brilliant!

The probes continued to work without config, and 2 of the 3 Shellies i'm using with temp probes showed the hardware ID listings more or less immediately. One was recalcitrant, and after 5 minutes I tried the status request, still to no avail - however a device reboot of the Shelly fixed things and it seems to be working perfectly. (I'll keep watch overnight.)

The only tweak I can think of which would improve usability would be to display the current correlation between probe number and hardware ID (its not in the Shelly UI that iI can find, so it requires something like MQTT explorer to figure which hwID relates to which probe number (assuming you cant deduce it from the temp reported).

cheers
adam.

Fantastic! I will have to keep exploring what causes that new /ext_ topic to be published.

As for the hardware identifier to channel association, the channel is included in the plugin menu action. I should be able to add the channel information for a hardware identifier to the dropdown so that it is a bit more clear while actually creating a device.

Thanks for testing,
Aaron

As for the hardware identifier to channel association, the channel is included in the plugin menu action.

of course....you even pointed that out!

Im currently configuring one of the temp/humidity sensors...Ill check that works too.

The only tweak I can think of which would improve usability would be to display the current correlation between probe number and hardware ID (its not in the Shelly UI that iI can find, so it requires something like MQTT explorer to figure which hwID relates to which probe number (assuming you cant deduce it from the temp reported).

This tweak should be present on the latest commit in the 0.5.0 branch with the channel shown next to the hardware identifier.

Screen Shot 2021-03-16 at 4.30.03 AM.png (132.27 KiB) Viewed 3819 times

of course....you even pointed that out!

Im currently configuring one of the temp/humidity sensors...Ill check that works too.

A real good test for it would be to have both a DHT22 and a DS1820 sensor connected to the same shelly. Allegedly the DHT22 will always be bound to channel 1...

A real good test for it would be to have both a DHT22 and a DS1820 sensor connected to the same shelly. Allegedly the DHT22 will always be bound to channel 1...

ah! okay i'll try that. I think i have a spare probe somewhere.

A real good test for it would be to have both a DHT22 and a DS1820 sensor connected to the same shelly. Allegedly the DHT22 will always be bound to channel 1...

ah! okay i'll try that. I think i have a spare probe somewhere.

I should clarify why this is a good test. Shelly stated that they only support connecting a single DHT22 and that the humidity portion of the sensor will be tied to channel 1. One would assume that this means the whole sensor is bound to channel 1, so the corresponding temperature entry in /ext_temperatures should also be channel 1, forcing the DS1820 to be channel 2 or 3. The plugin has no reliance on this, but I think some weird display issues could happen if thats not the case.

regarding what is triggering publishing of the ext-temp topics...I've been watching MQTT Explorer (such a good app!) and can see ALL those fields updating every few seconds. So I'm not sure what was happening with the the recalcitrant device...i probably should have just waited.