Iotawatt not uploading to local Emoncms server

Support
1

Hello. I’ve just installed in Iotawatt to replace an EmonTX and a Boredom projects 12 input version.

Once I’d improved the WiFi to stop the Iotawatt rebooting, that bit is working OK (despite using non-recommended Brultech CT40s!)

Unfortunately it isn’t getting data into my local server and the serevr access logs imply that the IotaWatt isn’t sending the right HTTP message.

Capture
Capture653×650 53.2 KB

is my IotWatt Emoncms configuration.

This is the server log message

192.168.0.193 - - [01/Feb/2019:13:50:31 +0000] “POST HTTP://192.168.0.3/emoncms/input/bulk HTTP/1.1” 200 56

and this is the server log message for a successful upload from the Emonpi

192.168.0.194 - - [01/Feb/2019:13:51:13 +0000] “POST /emoncms/input/bulk.json?apikey=3166ec7a70f812bxxxxxxxxxxxxxxx HTTP/1.1” 200 2

I’ve scoured this forum and the Emoncms forum to no avail.

Any ideas?

2

I have the same configuration as you with a local RPi running Emoncms and only the Server URL field and API key field are filled in; much like yours.

I would confirm that the API key you are using is not the “read-only” one, but the one that allows write access to your emoncms system. Can you confirm that you have the correct key?

3

Can you post the IoTaWatt message log?

4

Thanks for the reply. The apikey is correct, it’s the same as the one used by the Emonpi.

5

I’m not sure that the message log is going to be useful. It doesn’t seem to update as I would expect; the last message is more than 24 hours old, and the error is probably because I was trying various setup combinations. This is all the log from the previous restart.

** Restart **

SD initialized.
1/31/19 14:42:48z Real Time Clock is running. Unix time 1548945768
1/31/19 14:42:48z Reset reason: Software/System restart
1/31/19 14:42:48z Trace: 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:2, 18:3, 18:4, 18:5, 1:6, 1:3, 1:4, 1:5[21]
1/31/19 14:42:48z ESP8266 ChipID: 2518145
1/31/19 14:42:48z IoTaWatt revision 4.8, firmware version 02_03_21
1/31/19 14:42:48z SPIFFS mounted.
1/31/19 14:42:49z Local time zone: +0:00
1/31/19 14:42:49z device name: IotaWatt
1/31/19 14:42:49z MDNS responder started for hostname IotaWatt
1/31/19 14:42:49z LLMNR responder started for hostname IotaWatt
1/31/19 14:42:49z HTTP server started
1/31/19 14:42:49z timeSync: service started.
1/31/19 14:42:50z statService: started.
1/31/19 14:42:50z dataLog: service started.
1/31/19 14:42:50z dataLog: Last log entry 01/31/19 14:42:45
1/31/19 14:42:50z historyLog: service started.
1/31/19 14:42:50z historyLog: Last log entry 01/31/19 14:42:00
1/31/19 14:42:54z EmonService: started. url=192.168.0.3:80/emoncms, node=7, interval=10
1/31/19 14:43:01z Updater: service started. Auto-update class is ALPHA
1/31/19 14:43:01z WiFi connected. SSID=Whitwell-Unifi, IP=192.168.0.193, channel=11, RSSI -71db
1/31/19 14:43:02z EmonService: Start posting at 01/31/19 14:43:10
1/31/19 14:43:02z Updater: Auto-update is current for class ALPHA.
1/31/19 14:48:00z EmonService: Invalid response, retrying.
1/31/19 15:21:15z WiFi disconnected.
1/31/19 15:27:04z WiFi connected. SSID=Whitwell-Unifi, IP=192.168.0.193, channel=6, RSSI -92db
1/31/19 15:32:54z WiFi disconnected.
1/31/19 15:32:58z WiFi connected. SSID=Whitwell-Unifi, IP=192.168.0.193, channel=11, RSSI -56db
1/31/19 18:23:53z EmonService: Stopped. Last post 01/31/19 16:52:10
1/31/19 18:25:09z EmonService: started. url=192.168.0.182:80/emoncms, node=7, interval=10
1/31/19 18:25:10z EmonService: Start posting at 01/31/19 18:25:20
1/31/19 18:30:10z EmonService: Invalid response, retrying."

6

I’m wondering whether it’s an incompatibility with the versions of Emoncms that I’m using. The Emonpi is running v8.5 and doesn’t seem to accept messages from the Iotawatt either. The other Emoncms serveris v9.7 but running on a Windows machine with WAMP.

7

Just to be sure we are talking about the same thing, the Emoncms configuration that you posted shows a node ID of “IoTaWatt” and the log says the node ID is “7”. Have you changed that?

8

Yes, it was changed in my attempts to resolve the issue. Trying to see if alphabetic characters were a problem.

A bit of playing with direct urls reveals some inconsistency.

This
http://192.168.0.3/emoncms/input/post.json?node=IotaWatt&json={1:0}

creates a node called IotaWatt.

This

http://192.168.0.3/emoncms/input/bulk.json?data=[[0,60,1,2,3,4,5,6,7,8,9,10]]

creates a node called 60 with 10 entries.

This

http://192.168.0.3/emoncms/input/bulk.json?data=[[0,IotaWatt,1,2,3,4,5,6,7,8,9,10]]

generates an error message - Error: Format error, json string supplied is not valid

Having created Node 60 I tried changing the IotaWatt setup to use node 60 to see if it would use those, but it’s not looking good.

SD initialized.
2/01/19 22:12:16z Real Time Clock is running. Unix time 1549059136
2/01/19 22:12:16z Reset reason: Software/System restart
2/01/19 22:12:16z Trace: 8:8, 8:9, 1:2, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 1:4, 1:3, 10:2, 10:3
2/01/19 22:12:16z ESP8266 ChipID: 2518145
2/01/19 22:12:16z IoTaWatt revision 4.8, firmware version 02_03_21
2/01/19 22:12:16z SPIFFS mounted.
2/01/19 22:12:17z Local time zone: +0:00
2/01/19 22:12:17z device name: IotaWatt
2/01/19 22:12:17z MDNS responder started for hostname IotaWatt
2/01/19 22:12:17z LLMNR responder started for hostname IotaWatt
2/01/19 22:12:17z HTTP server started
2/01/19 22:12:17z timeSync: service started.
2/01/19 22:12:18z statService: started.
2/01/19 22:12:18z Updater: service started. Auto-update class is ALPHA
2/01/19 22:12:18z dataLog: service started.
2/01/19 22:12:18z dataLog: Last log entry 02/01/19 22:12:15
2/01/19 22:12:18z historyLog: service started.
2/01/19 22:12:18z historyLog: Last log entry 02/01/19 22:12:00
2/01/19 22:12:18z WiFi connected. SSID=Whitwell-Unifi, IP=192.168.0.193, channel=11, RSSI -56db
2/01/19 22:12:20z Updater: Auto-update is current for class ALPHA.
2/01/19 22:12:22z EmonService: started. url=192.168.0.3:80/emoncms, node=60, interval=10
2/01/19 22:12:23z EmonService: Start posting at 02/01/19 22:12:30
2/01/19 22:17:20z EmonService: Invalid response, retrying.

9

I don’t see the inconsistency:

The first example uses the /input/post.json API
The second and third examples use the /input/bulk.json API

When you use the .json variant, the data must be in strict Json format, which requires all elements of the array to be numbers. So 60 works for a nodeID but IoTaWatt does not.

IoTaWatt sends the data to the /input/bulk API without the .Json suffix. That is a looser format where I believe the handler parses the array with a php function that allows strings.

Bottom line, the nodename is a red-herring.

The error message is “invalid response”. So you are connecting to Emoncms and sending the data. Emoncms is responding with something other than “ok”. I don’t know how old version 8,5 is, but it may not respond with OK. It’s also possible that it predates allowing the node name to be alphanumeric, or even the format where nodename is included in the data array.

If you know how to use wireshark, you can look at what that response is, but bottom line I think you have a stale version of Emoncms that doesn’t support the bulk protocol that IoTaWatt is using.

10

Releases · emoncms/emoncms · GitHub indicates 8.5 dates from July of 2015
V.9.9.5 is the current one and it is at least 4 pages of release after 8.5. It is probably time to update your version of emoncms, there have been significant improvements in the last 3.5 years with thousands of commits. It also supports low write mode which is probably why you are still on 8.5

ARCHIVE low-write (v8.5) - Old emonpi/emonbase emoncms version (July 15 emonSD ready-to-go SD card image). Low-write mode is now available in v9.0. The low write version of emoncms is designed for running on SD cards. This is a cut down version of emoncms supports only the phpfina and phptimeseries feed engines (no in built feed averaging or histograms) and a reduced input processor set. Archived branch

1 Like
11

Unfortunately I have very little knowledge of the arcana of http syntax. I was merely looking for some sort of idea of whereabouts the system was broken.

12

I think @frogmore did the research. Your EmonCMS is 3-4 years old. There are a lot of users successfully uploading to more recent versions, including your other system. IoTaWatt uses all of the capabilities of bulk upload to be able to recover from communication or server lapses as efficiently as possible.

It’s unfortunate, but most of the support question that I get these days are for EmonCMS. Folks get the ioTaWatt running in an hour or so, and then spend the next couple of days navigating how to setup EmonCMS. They have made some inroads into trying to simplify it, but judging by the questions I get, are not quite there yet. In your case, now you need to do Raspian as well to upgrade.

An alternative for simple uploading is to use PVoutput, or influxDB. Another alternative is to just use the analytic tools of the IoTaWatt itself. It has more and finer resolution data than the Pi, and has good graphing tools for historical data.

13

Actually, the version that I’m using is 9.7. The emonpi with 8,x was merely used as a relay from the emonTX.

As it seemed most likely from the outset that the problem is incompatibility between the IotaWatt and the emoncms instance, I wasted most of yesterday updating the Emonpi and making a new installation of 9.9.5 on a new Rpi.

I use the principle ‘if it ain’t broke don’t fix it’ and the version of emoncms was working perfectly for me. My experience predicts that updating will be a world of pain and probably involve the loss or rendering inaccessible of 17GB of data.

14

Neither are practical solutions for my system. I want access to the large quantities of data that I already have. The 10 inputs of the IotaWatt are fairly peripheral. I’m logging about 165 feeds and I want to be able to view them with the dashboards that are set up in the current system.

What should have been a simple drop in replacement has turned into a nightmare. Backward compatibility! what’s that?

15

That would be my nightmare. IoTaWatt didn’t exist in 2015.

If you bought the IoTaWatt from me, I’d be happy to have you return it. Last thing I want is a dissatisfied user that doesn’t keep the firmware up to date. BTW, IoTaWatt automatically updates all systems regularly with no user involvement required.