Problems installing on Raspbian Stretch

[jeff]

@borpin

Try clicking ‘auto refresh’ above the logger window. You will then see the real time log. What Logging level are you set at? Set to LOG and you will at least see the call to get the latest log entries.

I don’t see an “auto refresh” button. Do you mean the inputs or the feeds window?

I’ve just changed the log level in /var/www/emoncms/settings.php to INFO, and now it logs every time I access emonCMS. Nothing else, though.

@Paul

Try sudo chmod -R 755 /var/lib/{phpfiwa,phpfina,phptimeseries}

I did this, and for good measure deleted and recreated the feed, but to no avail.

Thanks for the suggestions. Any other ideas before I flash the SD?

[pb66 (Paul)]

@jeff

I don’t see an “auto refresh” button. Do you mean the inputs or the feeds window?

No, on the admin page next to the logger window.

What sort of set up is this?
Do you have low write enabled in the settings? if so do you have the feedwriter installed and running?
Do you have redis enabled in the settings? If so do you have redis and the php extension installed and enabled?

How did you create those feeds? Was it via the input page and input processing?
Have you deleted any inputs or processlists?
can you show us your inputs page uncollapsed?

[jeff]

@pb66

No, on the admin page next to the logger window.

I was being blind. Found it, thanks.

@Paul

sudo chmod -R 755 /var/lib/{phpfiwa,phpfina,phptimeseries}

I evidently spoke too soon, because coming back to it after supper, I now have an hour of data!

@Paul

Once you get feeds to log ok, we can sort out assigning ‘units’.

Excellent! Please tell me how!

[Paul (Paul Reed)]

@jeff

I evidently spoke too soon, because coming back to it after supper, I now have an hour of data!

Great!

@jeff

Excellent! Please tell me how!

If you check Brian’s post (second from top), that link will explain, there is also a video on the same link.
If you get stuck with anything specific, please post.

Paul

[jeff]

@borpin

Yes the inputs mean nothing. It is the feeds that have meaning and are logged. Have you followed this bit of the Guide? emonCMS: Getting started emonPi/Base — OpenEnergyMonitor 0.0.1 documentation

In my case, the nodes have no names, and I have two more keys than in the video:

Where do I see what scaling factors to apply to turn the values coming from the emonTH into temperatures, humidities, etc.?

[Robert.Wall]

Everything from a standard emonTH has the original value multiplied by 10 to send as an integer, so multiply by 0.1 to return it to everyday units with one decimal place.

You can find that by looking at the emonTH sketch (on Github via Resources|emonTH|Firmware), or look at the "scales = " factors in emonhub.conf, if you have a copy.

[Hint: We normally only use 1, 0.1 and occasionally 0.01. But these multipliers can also be used as a fine calibration adjustment if necessary.]

[jeff]

@Robert.Wall

Everything from a standard emonTH has the original value multiplied by 10 to send as an integer, so multiply by 0.1 to return it to everyday units with one decimal place

Thanks. That makes sense for the temperature and humidity values, but not so much for the battery value (key 4). Why would a fresh set of batteries be producing 29?

What do keys 5, 6, and 7 mean?

[Robert.Wall]

This is lifted straight out of the emonTH sketch. It’s the instruction to emonHub on how to decode the data, and you’ll also find this in emonhub.conf :

emonhub.conf node decoder:
See: emonhub/configuration.md at emon-pi · openenergymonitor/emonhub · GitHub

[[23]]
  nodename = emonTH_5
  firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
  hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:OFF)
  [[[rx]]]
     names = temperature, external temperature, humidity, battery, pulseCount
     datacodes = h,h,h,h,L
     scales = 0.1,0.1,0.1,0.1,1
     units = C,C,%,V,p

In datacodes, h = signed integer (2 bytes), L = unsigned long (4 bytes)
Everything else should be reasonably obvious.
If you look further down the sketch

   emonth.battery=int(analogRead(BATT_ADC)*0.0322);                    //read battery voltage, convert ADC to volts x10

which ties in with the 0.1 multiplier.
If you’re getting 29 as an integer value, then it’s reading the battery voltage as 2.9 V. Are you running it on the battery, and nothing else (like the FTDI programmer)? We did have some faulty units slip through at the beginning of the year, but this doesn’t appear to be the same problem.

This always assumes that you have the standard sketch in your emonTH, and that you’re decoding the values using emonHub. I’m beginning to think that’s not happening, and you’re decoding the pulse count as two integers rather than a long, and the -28 is the RSSI (signal strength).

Do you actually have a Node 23 defined in your emonHub.conf?

[Paul (Paul Reed)]

@Robert.Wall

Do you actually have a Node 23 defined in your emonHub.conf?

@Robert.Wall If he installed via the build guide (post #1 this thread), he has installed @pb66’s original emonhub, not the emonpi version.

Paul

[jeff]

What are the differences between the two emonhub versions?

When I originally set up emonhub, I had put in what Robert suggested above. I’ve just updated it to remove the [[[rx]]] line and fixed the indentation of the remaining lines to match the first three. I am now getting data for one key fewer - 6, rather than 7, but still not 5.

[pb66 (Paul)]

@jeff

I am now getting data for one key fewer - 6, rather than 7, but still not 5.

That would be correct, the 2 integers will have become 1 long. giving you 5 values not 6, and then there’s the trailing RSSI value which isn’t defined in the payload, makes 7.

[jeff]

Excellent. Thanks for the clarification. Thank you everyone for your help.