More than 6 1-wire devices on an emonPi

Getting Started
1

Hi all,

I’m trying to add a bunch of DS18B20s to my new emonPi, but I see in the documentation that the configuration only supports a maximum of 6 with the default firmware.

A couple of years back I went through the 1-wire learning process on an Arduino and I still have sketches somewhere for enumerating all the 1-wire devices on the bus and then polling them. I can’t remember if it polled them by address or looped through all instances it found, but I do remember that I had a rake of DS18B20s reporting in to emonCMS on a pi over ethernet.

My question here is how/where do I modify the config of the emonPi? If someone can point me to the correct documentation area it would be great. Once I know where to make the change, I am happy that I know what change to make.

If it’s a question of compiling a new firmware from source that I have modified, is this something I do on the emonPi itself, or do I build it on my PC and upload the compiled firmware?

Or is it just a matter of changing a config file on the emonPi?

Thanks,

z

[edit] I have a couple of the SheepWalk Electronics SWE2b boards for easily hooking up multiple DS18B20s so physical connectivity isn’t an issue.

2

Unfortunately not.

It’s a sketch that’s remarkably similar to the emonTx sketch - because the “emon” part is a cut-down emonTx.

You can (allegedly, I’ve never tried) do it on the Pi, I prefer to do it on a laptop with the Arduino IDE, compile it there and then upload. That’s a two-stage process, but I have a script for it.

You need to download the “front-end” sketch for your Pi. It’s in the Pi, at /opt/openenergymonitor/emonpi/firmware/src and you need all the files in there. scr.ino is the one to edit. You’ll need to find and change:

const byte MaxOnewire=             6;

to however many you want, and I think that’s it.

Compile and save the executable, then you need to transfer it into the Atmel 328P via the Pi.
Because I’m doing it a lot (a clue for the reason is “CM”), I have a script to do it. Obviously, your Pi will have a different IP and the executable on your computer will be in a different place with a different name.

#!/bin/bash
# Generate a SSH key pair with "ssh-keygen" Don't set a password
# Copy to the Pi with "ssh-copy-id [remote id]  e.g.remote-id = '[email protected]', password "emonpi2016" is required ]
# Needs SSH & SCP on source machine. Avrdude should exist on the Pi.
remotemachine='[email protected]'
sourcefile='/home/r/OpenEnergy/Software/rfmNATIVE/EmonPiCM_radio/emonFrontEndCM/emonFrontEndCM.ino.standard.hex'
targetfile='/opt/openenergymonitor/emonpi/firmware/compiled/emonFrontEndCM.ino.standard.hex'
echo This can take about 45 seconds to complete
echo
scp $sourcefile $remotemachine:/opt/openenergymonitor/emonpi/firmware/compiled
# ssh $remotemachine cd /opt/openenergymonitor/emonpi/firmware/compiled
ssh $remotemachine sudo service emonhub stop
ssh $remotemachine avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:$targetfile
ssh $remotemachine sudo service emonhub start
exit

As you’re hopefully only doing it once (DON’T leave the only copy on the Pi, it will get overwritten if/when it does an automatic update on power-up), you probably won’t want to set up the pair of key files and use the script, just use whatever you’re happy with to transfer the file and issue the commands on the Pi via Wi-Fi or whatever. You’ll need the SSH password - emonpi2016

3

Increasing it too much risks the sketch being able to complete within 10s IME (but that was the old sketch).

I use a Wemos D1 Mini with Tasmota for my temperature sensors. It does have a limit of 8 sensors, but it is rock solid.

4

You really can and it really does work so nothing ‘allegedly’.

5

Thanks Robert & Brian. I’m almost there I think. I used a combination of the replies you gave. Having seen that it was possible to build and flash directly from the pi, I found this blog post which laid out the steps - Part 1/3: PlatformIO open-source embedded development ecosystem - Blog | OpenEnergyMonitor

In short -

  1. sudo python -c “$(curl -fsSL x://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)”
  2. git clone x://github.com/openenergymonitor/emonpi
    2a) cd emonpi/firmware
    2b) edit src/src.ino in the cloned directory
  3. sudo /root/.platformio/penv/bin/platformio run -t upload

It was all looking good with platformio installed in 1), the source cloned in 2), the MaxOnewire value increased in 2b), and the image built in 3), but then there was a problem writing the image -

Building in release mode
Compiling .pio/build/emonpi/src/src.ino.cpp.o
Linking .pio/build/emonpi/firmware.elf
Checking size .pio/build/emonpi/firmware.elf
Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
RAM: [===== ] 53.9% (used 1103 bytes from 2048 bytes)
Flash: [====== ] 60.3% (used 18526 bytes from 30720 bytes)
Configuring upload protocol…
AVAILABLE: arduino
CURRENT: upload_protocol = arduino
Looking for upload port…
Use manually specified: /dev/ttyAMA0
Uploading .pio/build/emonpi/firmware.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading input file “.pio/build/emonpi/firmware.hex”
avrdude: writing flash (18526 bytes):

Writing | ##############avrdude: stk500_loadaddr(): (a) protocol error, expect=0x14, resp=0x1c

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0xe0
#avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

I found the firmware.hex file that platformio built with my increased MaxOnewire setting, copied it over to /opt/openenergymonitor/emonpi/firmware/compiled, renamed it latest.hex and tried an upload from the web interface. That appeared to go better and when I rebooted the device told me it recognised 8 DS18B20s, so it looks like my change was effective.

Unfortunately it looks like there’s more work to be done though, as while my EmonTH is reporting data through the emonPi, the Pi itself (with the 8 probes) isn’t reporting anything.

6

So, from the information in the above post I have two main questions -

  1. does anyone know what’s causing the protocol error that is stopping platformio from uploading the firmware? It’s a ‘stock’ emonPi with no changes made to date, other than what is described above.
  2. where else might I need to change the config on either the emonPi or the CMS to get it to log and report all 8 probes?

Thanks,

z

7

You need to edit the node description in emonhub.conf to allow it to accept the new message that the front end is sending.

The emonPi itself is NodeID=5, which at present looks like

[[5]]
    nodename = emonpi
    [[[rx]]]
        names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
        datacodes = h, h, h, h, h, h, h, h, h, h, L     
        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
        units = W,W,W,V,C,C,C,C,C,C,p

You need to add two more “t’s” and their associated datacodes, scales and units. All 4 lines should line up left to right. So as you say 8 in total:

[[5]]
    nodename = emonpi
    [[[rx]]]
        names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,t7,t8,pulsecount
        datacodes = h, h, h, h, h, h, h, h, h, h, h, h, L     
        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,1
        units = W,W,W,V,C,C,C,C,C,C,C,C,p

N.B. I would never advise anyone to use platformio - it screwed up my laptop and it took me hours to recover. That’s why I suggested you did it on your computer and then did the transfer that way. You’d also have had the new source safe if your SD card dies or if an update overwrites everything.

8

pio on the RPi is a different beast. Basically a command line tool.

@TrystanLea

9

Did you edit the platformio.ini as per 3b at Part 1/3: PlatformIO open-source embedded development ecosystem - Blog | OpenEnergyMonitor?

10

The place to look for clues is in the emonhub log /var/log/emonhub/emonhub.log or via the emoncms WebUI.

11

Thanks Brian, I saw that the board was set to emonpi in the [env:emonpi] section and thought that was sufficient, but it wasn’t.

I changed the board to emonpi in [env:direct-upload] and this time it completed the write but failed on verification. I changed the value in [env:emonpi_deploy] and this time it worked, although the return message indicates that direct-upload and emonpi_deploy were ignored.

=================== [SUCCESS] Took 15.36 seconds=====================

Environment Status Duration

emonpi SUCCESS 00:00:15.364
direct-upload IGNORED
emonpi_deploy IGNORED
=================== 1 succeeded in 00:00:15.364 =========================

I think I have enough information from the posts from yourself & Robert to keep me going for the moment so I will bang away at it again later today.

Thanks for the help,

z

1 Like
12

Thanks for the help everyone. I have it running now. I’m still getting an intermittent protocol error when uploading from the emonPi using platformio, but re-running the same command a second or third time is normally enough to get it onto the board.

image
image1607×706 28.6 KB

I have 14 attached at the moment, and you can see them all reporting in the screengrab. Given that they are all sitting beside each other on the floor beside me I would have hoped they reported the same temperature, but that’s another days work. For my purposes I only need a very occasional reading (every 5 minutes is sufficient) and I really just need to see when the temperature changes (as it’s monitoring heating water flow for under-floor heating).

If it helps, I’m happy to write some step by step documentation for a similar use case. The steps were pretty much as outlined above - on a stock emonPi download platformio, download the source[1], edit the relevant .ino file, compile and upload, edit the emonhub.conf, drink coffee, done.

z

[1] possibly not needed as I think I saw there was a copy of the source on the emonPi already

13

They could all be within specification, except for one (t4). From the data sheet:
“±0.5°C Accuracy from -10°C to +85°C”
so the spread from the lowest (21.8°C) to the highest below t4 (t11 at 22.7°C) is within that 1 degree spread. 85 °C (t6) is a fault - it was asked for the temperature but it hadn’t seen the command to “convert” first. This could be a loose wire.

Take a look here, if you haven’t already: Ds18b20 and emonTX3CM firmware. It’s a long thread. Down at post no.65, there is 'scope picture of the timings for reading two sensors, but using emonLibCM, NOT using the emonPi as you have it - I think it will take that amount of time - 375 ms with 11-bit resolution) for each of your 14 sensors.

And further down at post no.78, there are timings for a whole range of “cloned” sensors. If one sensor is always significantly different to the others, check its serial number against that list.

If you found you needed to repeat a command two or three times to get it to take effect, that tells me there’s something not right with the procedure you are following. Advising others to follow that procedure isn’t likely to leave you in the best light.

1 Like
14

I don’t think it will reflect badly on me, it will reflect what happens in practice when compiling and writing the image with everything fresh out of the box.

Obviously, I aim to find out what’s wrong with the writing part and get that working as expected. I will be doing a factory reset in a while and running through it from start to finish to confirm that it all works as expected. I’m happy with the progress to date and am thankful for the assistance provided above.

z

1 Like