Temperature Sensor IDs in emonPi2 not matching inputs

I’m setting up some temperature sensors with emonPi2 and noticed that the IDs on the Input Screen do not match the IDs in emonHub. I need to delete one of the inputs but don’t know which is which in emonhub.

Here is the info from emonhub

        Type = EmonHubDS18B20Interfacer
            pubchannels = ToEmonCMS,
            read_interval = 10
            nodename = sensors
# ids = 28-000008e2db06, 28-000009770529, 28-0000096a49b4

and here is what shows up on the Inputs screen.
Any suggestions as to how I go about matching them up?


I think those numbers are examples.

It should pick the data up automatically, so if you are seeing the data on the Inputs page (which it looks like you are), then you are good to go to create a Feed for each.

Yes, they look like examples. Could be better illustrated than this - not sure if the link above is the correct place to suggest an edit @TrystanLea ?

It probably also needs a link to the download for the sketch to read the DS18B20 serial number, as well as the equivalent script for the RPi – when someone (I’m looking at you, @TrystanLea :smile: ) gets round to adapting and packaging this as a script: Raspberry Pi DS18B20 Temperature Sensor Tutorial - Circuit Basics to run off the Admin page of emonCMS .

1 Like

Of course - I should have noticed the hash before the ids - I’m learning, albeit slowly.
thanks for the help.

Works perfectly. Below is my before and after in case anyone else would like to see how the emonhub edits are applied.

Here are my inputs before any edits and plugging in the temperature probes.
And emonhub before any edits.

Then the edits to emonhub are made.

And finally the new inputs. Note: I had to manually delete the old inputs under sensors.

Thanks to Brian for reminding me why the hash sign is there in the first place!

Best regards,


1 Like

That’s expected. New inputs appear automatically. It has no knowledge that an old one isn’t going to reappear, so it will never be deleted.

I added the option to set the ID’s manually here and have them renamed to the listed names, but in practice I never use this myself. I just let the actual sensor ID’s come through to the inputs page and add one sensor at a time so that I know which sensors Im connecting.

I think this is simpler and supersedes uploading a sketch to the EmonTx4 or emonPi2 in order to list sensor addresses?

Perhaps for clarity I should add to the emonHub comment something like:

# Sensors are detected automatically
# sensor will automatically appear on the emoncms inputs page 
# identified by the sensor address e.g (28-000008e2db06) 
# Tip: Add one sensor at a time in order to match the address to the sensor.
# Optional: If the sensor addresses are known e.g by first reading the address
# as printed on the emoncms inputs page it is possible to list these addresses here 
# and rename them to more legible names, uncomment and replace the following
# configuration example with your sensor addresses and choosen names.
# This is usually more trouble than it's worth as it's easy to assign descriptions
# to input names in the emoncms input list but may be useful if accessing 
# sensor data outside of emoncms e.g via the MQTT topics generated by emonHub
# ids = 28-000008e2db06, 28-000009770529, 28-0000096a49b4
# names = ambient, cyl_bot, cyl_top

Don’t forget the big problem that arises when a sensor fails and is replaced. All the sensors are likely to occupy new positions (due to the discovery algorithm for the One-wire bus) and will need reassigning unless the serial numbers have been fixed in the array (hard coded, EEPROM,or whatever).

This is the big benefit of this new approach, these addresses are fixed and dont occupy new positions - if a sensor is removed. Which means we finally have a solution to that issue for users who attach temperature sensors to the emonPi2 where the temperature sensors are read via emonHub as above.

Not having a Pi2, I wouldn’t have been able to know this.

1 Like