I have experienced situations when a 200 response has been issued but the data has not actually gone into the input. I don’t remember the exact situation, I think it was some malformed data or a timestamp issue. The http response is also not consistent across different input types which I do appreciate is difficult to fix as emonhub (I believe) looks for the ‘ok’. It has made me less than confident that a 200 really does mean all is well.
However, I’ve not handled that well so I am looking at it again. I think I will output the 200 response and leave the user to decide if it is an issue or not.
Yes I don’t disagree. It is the way I’m handling it at the moment. Looking for a more elegant solution (which I suspect is simply updating the status text to say ‘http 200 response’ when that is what is received but learning about node.js http module ATM.
But that would mean that the message would be made everytime it sends data. I can’t recall any other node that does that, as they usually report by exception when there’s a problem…
I have worked on the module today and have added a number of modifications.
Improved the decoding of the http response to look explicitly for the JSON type response ‘success’ and the non-json response ‘ok’ (these responses can be seen by using the API help URLs)
Improved handling if for example, the requested server or address is incorrect or unreachable.
Modified the text to indicate the response and the HTTP response code.
Removed some warnings.
Added in a timeout but have not been able to test this functionality.
It is just the status text I am updating now, so yes it updates each time, but you never notice it if everything stays OK. (Examples of responses) Obviously, if it is not a green then you get a debug message.
That’s a much better solution Brian. I wish more nodes would make better use of ‘status text’, as it’s discrete, and doesn’t fill up the debug panel with messages.
I’m in the middle of something at the moment, but hopefully I’ll get chance to try it in the coming days.
Apologies for my duh! moment on the 200 response. Not being an expert in http and it being mentioned as an issue I had assumed that it was something we would want to warn about.
The solution you’ve made looks great though, thanks Brian.
One caveat to that, if all other types of node simply show a green indicator without any message in normal situations then shouldn’t we drop the message and just show the green indicator. Having the message when there is an issue is great as it helps to debug things.
If you get a chance to try the node and see if there are any further comments. You just need to overwrite the .js file in the nodes folder and restart node-red.
… and it is working fine for me (I am using emoncms.org)
Excellent job - thanks a lot.
There was one little thing I noticed which happened the first time you upgrade to node-red-node-emoncsm version 0.1.0: although data type is prefilled with “Legacy Processing” you must explicitly set it again to “legacy processing” and redeploy the flow to get it properly working.
Yes that is expected for the node. It goes back to my earlier comment that a 200 response code does not necessarily mean a successful data input. The 200 code is hard coded in EmonCMS, but the text that comes back is not OK or success. You should see the actual error message in the debug window.
