In the browser correctly returns a CSV version of the data.
However, if I copy-paste that exact command into a node-red http request node, I get the HPE_INVALID_CONSTANT error reported as per this screen shot, which then says that ‘HTTP /’ was expected. any hints as to what I may be doing wrong?
Not a node-red user, but from what you posted, the error detail appears to be from the payload node that has received the 150 byte payload listed. That is not an error that would come from IoTaWatt. It looks like something that node-red is telling you about the HTTP request.
So I think you need to back-up to the http request node and get some details about the HPE_INVALID_CONSTANT. Can you show the node settings and any diagnostic information that it associates with the http request node?
IoTaWatt uses HTTP 1.1 which supports chunked response. Chunked response is used when you don’t know at the outset how much data will be transferred (which we don’t). So IoTaWatt sends “chunks” with a length header. That should be supported in Node Red. Do you have the latest version installed?
EDIT: Also, does Node Red have any further information for the HPE-INVALID-CONSTANT message being reported in the HTTP request node?
I was running node-red 1.2.3 and now updated to 1.2.5, still the same unfortunately.
I will try and dig out any other error info reported by the node, but at the surface, it appears that the parsing of the response failed in node red… let me see if I can find something additional on there…
The way I read it, the http request node does the request and then passes the response string to the msg.payload node. So what happens when something goes wrong with the http request? I’m thinking it passes an error string to the next node, and that’s what we see in:
IoTaWatt has no error message that anything remotely like that. So my take is tat there is something about the URL that the http request node doesn’t like.
This is half-baked research, but a quick look at some forum posts suggests that node-red parses the query (part after the ?) of the URL. The IoTaWatt query is a litlle complicated and I wouldn’t be surprised that node-red would have trouble with it.
So looking at this
It appears you can pass the URL as a quoted string using a “function node”. That might eliminate parsing the query, and thus the error. I’m not sure how all this goes together, but it seems clear to me that node-red is trying to parse the URL and having difficulty, so an alternate means of specifying the URL that bypasses the query substitutions might be the fix.
Like I said, I know very little about node-red, but that’s the path I would explore.
You might try asking on the node red forum. Looks like a lively bunch.
Ok will do - looks more like a node red issue, since, after doing the above, as well as even simplifying the query even further to just the “HTTP://iotawatt.local/query?show=series” query, still fails with the same error. Thanks for the guidance so far - I will ask over at node-red (same username there )
I did try JSON response  and it too resulted in the same error as the utf8 string. I also tried empty  brackets (which yielded an error about an array). I tried many other items too such as no parameters at all, escaping or double-quoting ampersands too.
Specifically for the combo you’ve asked for, here’s the options. Do I need to use digest authentication by any chance?
If you have a password set in your IoTaWatt you would need to authenticate. Rather than try to use Digest Authentication (which woul dbethe correct choice), I’d try to get it working with no authentication first by removing the password (set it to blank in the IoTaWatt).
TBH I had not explored the Node-Red capabilities before, but it looks as if it could easily satisfy the MQTT output needs that folks have been asking for. So I’m running this issue to ground.
I’m pretty sure it’s about the chunked response, so I have joined your thread on the Node-Red forum to follow up with a few apparent regulars who appear to have looked at this issue back in March. I think they got it wrong, but maybe between us this can be resolved.