yeah, i've been planning on putting together basic flows for download so that folks can configure, calibrate, and use these Atlas-Sci sensors and circuits with no worries. Still working on the EZO Dosing pumps..
The dosing pumps would be a nice addition.
But as long as the Ph and EC is working I'm where I need to be 
Using analoge sensors for the moment, and realized the Atlas ones were i2c/uart 
Atlas-Sci does produce a line of analog transmitters for their probes called 'Gravity'.
However, the i2c is no issue with Node-Red. The only issue might be isolation... are you using them with a Whiteboxlabs Tentacle shield or the Isolated Carrier Boards?
If you are considering the Whitebox Labs Tentacle T3 shield to use with a Raspberry Pi..... be mindful that a version 2 board is soon to be released (a matter of 2+ weeks or so) that adds a few nice extras (better integration of the EZO Flow circuit and daisy chaining of the i2c bus). If those aren't important to you, the existing Tentacle T3 is very good (I use two of them stacked for this project)....
I have seen the analoge sensors, but the EC sensor doesn't come in a gravity variety.
Also, I'm kind of forced over to i2c/uart because of isolation, as the Ph sensor I used (cheap Chinese) made me aware of a ground loop I had (which killed of my Ph probe).
The TDS sensor I use can deal with the ground loop, but it is really just an indicator as it doesn't measure true EC, but purely conductivity.
In regards to using a hat, I looked at the tentacle shield but were uncertain as to which gpio it uses and if I could use the other gpio's independent of it?
Mainly the idea was to use the gen2 carrier boards.
Today im using hassio on PI, with sensors and relays going through a Firmata arduino uno.
I'm hoping to cut out the Uno as it's been the only source of errors this far.
I don't suppose your flow would work with Node-red on hassio, but I can live without it as I mainly use hassio for logging and remote connection, all the programming goes through Node-red.
While running node-red on raspbian would allow me to use the same PI for interfacing, so there's give and take with both options.
The Tentacle T-3 isn't really a true shield... it just routes a few pins (power, ground, i2c) to the appropriate headers for the EZO circuit/stamps.
My flows have nothing that is PI unique except for the 'System Tab' that shows hardware status (temp, memory, ipaddress, etc..).
Regarding EC... I am not taking all 3 available measurements from probe... Just Conductivity, but not Salinity, nor TDS. Likewise on FLO, I just take a simple instantaneous FLO, but at the moment I am not totalizing. That's just becuase I have done any serioius parsing of the return string from the EZO devices to seperate out distinct variables. I need to get on that.
My primary flow is in a little bit of disarray at the moment as I'm changing things around... However, the reading/writing of the EZO devices has not changed, so you can glean that...AtlasScientificNCDDeviceFlows.json (105.3 KB)
Haven't updated in a bit. However, I did add a the Ambient Humid/Temp sensor from Atlas Scientific. This led me to tackle retrieving two different attributes from one sensor over i2c and parsing out the results...
That led me to tackle the same for EZO-EC, where I'm retrieving Total Dissolved Solids and Salinity in addition to the original Conductivity.
Same for the EZO-FLO, where I'm retrieving Total Volume as well as Instantaneous Flow.
The flows need allot of work as they are getting ungainly... however, I'll still share them so that you can see how the parsing of the i2c messages from the ezo devices is accomplished...
FullSonoranDesertFishNookDIYFlows.json (195.4 KB)
Continuing work. Here I have 3 EZO Pumps working. THis is key, because I had been relying on the Device Type to indetify sensors types and store the i2c address. Obviously having 3 EZO Pumps all with the same device type of PMP (returned by the 'i' command) wasn't going to work. I didn't like the idea of hardcoding in the i2c addresses. So I've come up with another solution. I just require folks to assign a Name to each of the device that is an increment of the Device Type. So the 1st PMP Device becomes PMP1, the 2nd becomes PMP2, etc... Yeah, not the neatest, but I'll add a new attribute called Description (Desc) where folks can go wild (eg. MacroDosing, MicroDosing, etc..). Because I have to prebuild the flow and dashboard groups and nodes, and then enable and disable them as appropriate (need to figure out how to do that on startup), I needed some form of naming convention that I can rely on.... that's one limitation that I will be forced to live with for now.
Folks,
I want to give a shout out to MaddyTP (GitHub id) for developing a node-red-contrib-ezo node that makes communications with Atlas-Scientific EZO circuits, sensors and devices much easier. Doing some more testing on it, but preliminary results are very positive for simple reads of Temperature, Conductivity and pH.
(ps. going to update my sample flows to include this node.)
2 Likes
Glad to help! I will continue developing the Ezo node with recommendations from the community. 
2 Likes
Hi
one thing that would be good would be if you could re-use the incoming msg for the outgoing results... thus keeping any extra properties on the msg...
If I add a topic to the inject (eg Humidity) it would be good if that was preserved as it was passed through the node.
And likewise it would be nice if the label was actually the type I selected rather than the short value you have picked. ie Humidity rather than hum.
Tiny nits - as it works just great ! Thanks
1 Like
David,
now you can keep track of all of those cool damp summer days. ooppss .. sorry...
indeed - not too hot / not too cold - and only 54% today..
Excellent ideas! I'll add these to the next update.
What is the best practice concerning empty msg.payload? Leave it as an empty string or drop the property altogether? Several of the ezo commands respond with a success byte only, not sure how best to handle it. Right now the node sends an empty msg.payload...
1 Like
The success is in the form of *OK, or *DONE, etc... I'd like to receive it. Some commands like a 'CLEAR' to the EZO-PMP will CLEAR the total Value Dispensed. I like to know that the command was acknowledged, so the *OK is great.
The case of a X for Canceling a dispense command it will return a *DONE, with the value dispensed. All of these Status Codes can be useful.
A D for dispnse command will return an *OK that the command was acknowledged.
a CAL,? command will return *OK to let you know that a device has been calibrated.
I think that these are useful.
The hardest command is the R for Read... It returns different things for different devices.
Here's an idea MaddyP... if you recieve something that begins with an *, you know that it is an Acknowledgement of sorts.... You could send that result... upto the first comma that you encounter as a msg.acknowledge .... anything after that could go to msg.payload... well almost there others too.. maybe read on..
The hard part is when you follow some commands with a ,? then the results that you get are odd...
Going back to the EZO-PMP example... a D,? is useful to see if the pump is still dispensing... but it returns ?D, *, 1 ... in this case ?D is a Command ECHO, * is an Acknowledgement, and 1 is the actual Status Value 1= actively dispensing, 0= would be not dispensing.
Sorry for the long answer... But I think you could apply some rules as you parse what is returned by the command..... ?whatever could always be interpreted as msg.commandecho (or msg.cmndecho), *whatever could always be interpreted as msg.acknowledgement (or msg.cmndack), and everything else after those could be msg.payload. You'd have some additonal message properties, but it would help folks with parsing the payload especially on the 'R' (read) commands where sometimes you get allot of values (eg. EC, HUM, FLO). I can see a case where the payload would be blank as the command isn't sending anything beyond a cmndecho or cmndack.
Including the msg.command gives a second degree of identification to the payload which might be received. For example, the *DONE,n would result in:
msg = { command: 'X', payload: ['*DONE', 50.00] };
Which could then be identified by the command and whichever property of the payload you wanted:
msg.payload[0] or msg.payload[1]
I don't really see the need of an additional property. In fact, I've improved the error handling for the next version so the msg.status property is no longer needed. If a message is sent it was successful, otherwise it will throw an error / warning depending on the result which could be caught by the 'Catch' node.
MaddyP,
I support the way you are doing it 100%. I would however, make it clear in you documentation that the user must know that they need to Split the payload and then know what element of the array they are looking for. A couple of simple examples in your documention might be needed. My long drawn out suggestions were just to cull the echos and acknowledgements, leaving the user to just work with a payload that would have either returned a single value, multiple values or NULL.
Your way is simpler, provided you supply examples to the users of splitting the payload. That's the part that I've had to help users with .... what to do with the payload that has multiple parts... Once I explain it... and point out what each command returns from the documentation ....well they get it.. A couple of well placed examples and users will use this node successfully out of the gate. It's good stuff!
If you like.. when you produce the next version of it, perhaps I can work with it for some of the harder device/command combinations (eg. pump dosing/cancel/statusupdate, etc...) to produce a some samples where a JOIN or Function node might need to be used... to feed a command with a payload. That's another spot where users were tripped up...
1 Like
Yeah, I certainly need to improve the README file to include different examples. Atlas Scientific doesn't make it easy for us though, their commands/responses are all over the place. I'll do my best to keep things simple and improve documentation.
Agree... I've scolded Jordan at Atlas-Sci on that... 
. Just kidding. This node is good and sorely needed. I can only offer suggestions from my personal experience working with the Atlas stuff, my kludges and shortcuts.. The seasoned programmers here will really be of help with conventions and best practices.
One suggestion.... I put up a quick announcement of this node because 1. you're too modest and 2. lots of people have continually asked me about developing nodes / flows. That would be a great thread to illicit opinions/suggestions from the really seasoned developers/users here.
1 Like
You are entirely too kind!
