Widgetlords Controller - Node-Red, Raspberry Pi Controller Build

[MaddyP]

Yes, they are a bit noisy.... They have released a new, larger pump called, PMP-L . I haven't tried it as I'm fine with the three that I have.

I've been testing out a new MarkII Tentacle-T3... White Box Labs sent it to me to evaluate for them. It supports the EZO-FLO stamp with a small 3 screw terminal for attaching flow meters. They also have a nice 'aux' Connector that allows you to extend the i2c bus beyond the board. Looks good. This is a prototype, so it will be interesting to see how it looks in it's production format. They've got a few more underdevelopment... They showed me schematics of a new one for the Pi-ZERO-W... I like that one... They also spilled word of a Tentacle-T8 (but didn't have anything to show me)..

Atlas-Sci is also selling a little 'bus expander of sorts'.. or 'i2c hub of sorts' called the Sensor bridge... Really useful for the 5 pin devices (like EZO-PMPs, EZO-HUM) devices.... as you just make one home run back to the RaspberryPi or Tentacle board.

So yeah, I'm definitely bought into the atlas-sci and ncd-io 'ecosystem'.. LOL.

Surprised you felt like you had to go all the way to 8GB.. My flows are super complex (albiet not as much trending as you are doing), and I'm finding my 4B w/ 4GB to be sufficient for now. I'm going to work with InfluxDB, Grafana and MQTT on this Raspberry Pi in conjunction with NodeRED.... but alas, I need to finish up this refactoring I'm doing now.

Woah! You've got me excited about new Tentacle board possibilities!

Funny enough, I built a Node-Red node over the weekend to facilitate communication to these devices. I'll publish it this week once I work out a few lingering issues. It'll handle both default and custom I2C addresses, store temp compensation in context, and support all current commands published by Atlas Scientific. Output is also grouped by command, status, and values.

 

[FischAutoTechGarten]

Woah! You've got me excited about new Tentacle board possibilities!

Funny enough, I built a Node-Red node over the weekend to facilitate communication to these devices. I'll publish it this week once I work out a few lingering issues. It'll handle both default and custom I2C addresses, store temp compensation in context, and support all current commands published by Atlas Scientific. Output is also grouped by command, status, and values.

That's awesome. I sent an EZO-HUM over to the developer at NodeRED.org that has taken over the i2c-contrib node (DCEEJAY). Just so that he could see what we do with the i2c-contrib nodes to make them work with the Atlas-Devices. (I also sent him a few other relay boards, pwm boards, etc... so that he could work with other i2c enabled chips... just in case vendors ever stop supporting them...)

We think we might have found a few dependencies that the current contrib-i2c, MCP83008 and other i2c nodes have that cause trouble when upgrading to Node14... so now I'm staying at Node12.. I'll fire up a new from the gound up RaspberryPi4B,64bit OS w/ 32bit userland, Node16, NodeRed1.35 etc.. , install the custom nodes... and see what happens. Let me know if you ever had issues with the i2c stuff after upgrading to the latest and greatest..

Back to your custom Node Development...

Are you handling multiple outputs for readings? (example the EZO-EC can return Conductivity, TDS, Salinity and SpecificGravity.. I disable SpecificGravity.... the EZO-HUM can return Humidity, Temperature and DewPoint... but it has weird punctuation around the DewPoint.. so I just disable DP anyway..... The Flow of course has Instaneous Flow and Total Volume... and I use both)... For multiple values on the read return, I just parse out the results of the read, looking for a comma... much like you do when extracting a device type form the reults of an info command.

Are you enabling things like zeroing a Total for the FLO, or Cancelling a Dose for a PMP?

You are doing real-time temperature compensation.. Will you allow for other types of compensation? (for instance with the Dissolved Oxygen you can bring it Temperature from an RTD and do Temp compensation, you can bring in Pressure from an EZO-PRS and do Pressure Compensation, you can bring in Salinity from the afforementioned EZO-EC and do Salinity Compensation.)

I did a quick spreadsheet to keep track of multiple instances of the same type of devices as I was trying to come up with a rules based means to automatically set i2cddresses and Names as Devices were discovered.... But there really was no substitute for hooking up a Termite Session and setting those manually.... anyway, here's the spreadsheet of default i2c addresses of all known Atlas-Sci devices... and a few provisions for multiples of pH, Flow, Temp and Pumps. Might save you from constantly having to look those up in individaul data sheets.

 

[MaddyP]

That's awesome. I sent an EZO-HUM over to the developer at NodeRED.org that has taken over the i2c-contrib node (DCEEJAY). Just so that he could see what we do with the i2c-contrib nodes to make them work with the Atlas-Devices. (I also sent him a few other relay boards, pwm boards, etc... so that he could work with other i2c enabled chips... just in case vendors ever stop supporting them...)

We think we might have found a few dependencies that the current contrib-i2c, MCP83008 and other i2c nodes have that cause trouble when upgrading to Node14... so now I'm staying at Node12.. I'll fire up a new from the gound up RaspberryPi4B,64bit OS w/ 32bit userland, Node16, NodeRed1.35 etc.. , install the custom nodes... and see what happens. Let me know if you ever had issues with the i2c stuff after upgrading to the latest and greatest..

Back to your custom Node Development...

Are you handling multiple outputs for readings? (example the EZO-EC can return Conductivity, TDS, Salinity and SpecificGravity.. I disable SpecificGravity.... the EZO-HUM can return Humidity, Temperature and DewPoint... but it has weird punctuation around the DewPoint.. so I just disable DP anyway..... The Flow of course has Instaneous Flow and Total Volume... and I use both)... For multiple values on the read return, I just parse out the results of the read, looking for a comma... much like you do when extracting a device type form the reults of an info command.

Are you enabling things like zeroing a Total for the FLO, or Cancelling a Dose for a PMP?

You are doing real-time temperature compensation.. Will you allow for other types of compensation? (for instance with the Dissolved Oxygen you can bring it Temperature from an RTD and do Temp compensation, you can bring in Pressure from an EZO-PRS and do Pressure Compensation, you can bring in Salinity from the afforementioned EZO-EC and do Salinity Compensation.)

I did a quick spreadsheet to keep track of multiple instances of the same type of devices as I was trying to come up with a rules based means to automatically set i2cddresses and Names as Devices were discovered.... But there really was no substitute for hooking up a Termite Session and setting those manually.... anyway, here's the spreadsheet of default i2c addresses of all known Atlas-Sci devices... and a few provisions for multiples of pH, Flow, Temp and Pumps. Might save you from constantly having to look those up in individaul data sheets.

Great news! Just published the initial version for testing. Take a look and let me know what you think. I've kept it very simple to support existing functionality.

node-red-contrib-ezo

Node to communicate with Atlas Scientific Ezo modules over I2C.

flows.nodered.org

Please be kind, this was my first time publishing...

Repo:

GitHub - MaddyTP/node-red-contrib-ezo: Node-Red node to communicate with Atlas Scientific Ezo modules over I2C.

Node-Red node to communicate with Atlas Scientific Ezo modules over I2C. - MaddyTP/node-red-contrib-ezo

github.com

 

[MaddyP]

Are you handling multiple outputs for readings? (example the EZO-EC can return Conductivity, TDS, Salinity and SpecificGravity.. I disable SpecificGravity.... the EZO-HUM can return Humidity, Temperature and DewPoint... but it has weird punctuation around the DewPoint.. so I just disable DP anyway..... The Flow of course has Instaneous Flow and Total Volume... and I use both)... For multiple values on the read return, I just parse out the results of the read, looking for a comma... much like you do when extracting a device type form the reults of an info command.

This node sends values in msg.payload. If there are multiple values such as the EZO-EC, it will send an array.

Are you enabling things like zeroing a Total for the FLO, or Cancelling a Dose for a PMP?

All commands currently supported by Atlas Scientific are supported by this node. In fact, I don't do anything with the input message except converting it to a Buffer for the ezo board to read properly.

You are doing real-time temperature compensation.. Will you allow for other types of compensation? (for instance with the Dissolved Oxygen you can bring it Temperature from an RTD and do Temp compensation, you can bring in Pressure from an EZO-PRS and do Pressure Compensation, you can bring in Salinity from the afforementioned EZO-EC and do Salinity Compensation.)

Temp compensation needs a bit more work, but my plan is to offer an option of saving the temp compensation value to context and reload on a reset. Should be simple enough, I'm already doing this with another node reloading the state on reset.

I did a quick spreadsheet to keep track of multiple instances of the same type of devices as I was trying to come up with a rules based means to automatically set i2cddresses and Names as Devices were discovered.... But there really was no substitute for hooking up a Termite Session and setting those manually.... anyway, here's the spreadsheet of default i2c addresses of all known Atlas-Sci devices... and a few provisions for multiples of pH, Flow, Temp and Pumps. Might save you from constantly having to look those up in individaul data sheets.

Multiple ezo boards are supported with the custom address option. Simple change the address and check the "Custom" option, an address field will become visible for user-defined I2C address. You will also notice if you check the node 'Help' section, I've included direct links to the documentation:

 

[FischAutoTechGarten]

Maddy...
I installed the EZO node... It wasn't available in the Palette manager so I just installed via NPM on the command line.
Briefly tried it on a spare RPi4B that had an RTD and pH probe connected... Worked good.. replaces 4 nodes, with 1.

Curious to try it with one of my Dosing Pumps where I pass in a variable desired quantity (based on a slider object in the dashboard) as part of the payload...

 

[MaddyP]

Maddy...
I installed the EZO node... It wasn't available in the Palette manager so I just installed via NPM on the command line.
Briefly tried it on a spare RPi4B that had an RTD and pH probe connected... Worked good.

I'd add a note that you must pass the command as a payload.... and of course, don't include quotes around the command.

I noticed it wasn't showing the Palette manager also. Not sure if there is a delay or approval process? I following the publishing instructions on the Node-Red website though.

Like I said, it's a very simple node to facilitate communication in an easy way. Let me know if you run into any issues, I've only tested it with RTD/EC modules, but all the commands/responses are structure the same way so should work on all modules.

 

[FischAutoTechGarten]

I noticed it wasn't showing the Palette manager also. Not sure if there is a delay or approval process? I following the publishing instructions on the Node-Red website though.

Like I said, it's a very simple node to facilitate communication in an easy way. Let me know if you run into any issues, I've only tested it with RTD/EC modules, but all the commands/responses are structure the same way so should work on all modules.

Maddy, I'm going to experiment doing calibration of the pH probe using your node. That should be straight forward. What will be more challenging is performing a calibration of the EZO PMP becuase I will have to use a Join node to stuff the payload.. I'll let you know how those work.

Do you care if i employ this node in a few revised sample flows that I am going to publish on NodeRED and distribute to Atlas-Sci and WhiteBox Labs? You will get full credit for that Node (I'll reference your GitHub Id). I'll make an announcement in the NodeRED forums too (folks often contact me via private messages on the NodeRED forum to get their Atlas-Sci stuff working). I think the presence of an actual EZO node in NodeRED as well as some solid examples of how to accomplish some of the harder things (calibrations, commanding pumps, parsing out multiple returned values) might convince more people to use them. Of course as more people use them, well then you and I can learn from those folks as well...

 

[MaddyP]

Maddy, I'm going to experiment doing calibration of the pH probe using your node. That should be straight forward. What will be more challenging is performing a calibration of the EZO PMP becuase I will have to use a Join node to stuff the payload.. I'll let you know how those work.

Do you care if i employ this node in a few revised sample flows that I am going to publish on NodeRED and distribute to Atlas-Sci and WhiteBox Labs? You will get full credit for that Node (I'll reference your GitHub Id). I'll make an announcement in the NodeRED forums too (folks often contact me via private messages on the NodeRED forum to get their Atlas-Sci stuff working). I think the presence of an actual EZO node in NodeRED as well as some solid examples of how to accomplish some of the harder things (calibrations, commanding pumps, parsing out multiple returned values) might convince more people to use them. Of course as more people use them, well then you and I can learn from those folks as well...

Feel free to use/share how you will. I'm planning to implement the option to send a command using both the msg.command / msg.payload to overcome the issue you've mentioned. It will convert both to strings, splice with comma, convert to buffer, then send to ezo board. This will be in addition to sending a standard string as it is now.

 

[FischAutoTechGarten]

Feel free to use/share how you will. I'm planning to implement the option to send a command using both the msg.command / msg.payload to overcome the issue you've mentioned. It will convert both to strings, splice with comma, convert to buffer, then send to ezo board. This will be in addition to sending a standard string as it is now.

You bet! I'm in a good position to test for you. I have:
3 EZO-PMP (latest rev), 2 EZO-pH (different revs), 2 EZO-FLO (different revs), 2 EZO-RTD (different revs), 1 EZO-DO, 1 EZO-EC, 1 EZO-HUM, 1 EZO-ORP.

Yeah, that's how the existing contrib-12c node works.. it recognizes msg.address and msg.command as well as msg.payload...

I did something odd with the dosing pump to stuff in the desired dose.... I stored the value of a slider to a variable and then did the stuffing in a function node. Now that I better understand the JOIN node, I think I can do it with less complexity. Here's what I did before... Need to rework it for a Join. (also need to save that dose schedule in this example to a file to pull it back up on restarts.... it think I missed updating the sample with that... I'll do that when I modify it for a Join and your new node...).

Heads up, the node is showing in the Palette Manager now.... I just installed it on a 2nd RpI4B via that method. I guess it was a delay...

 

[MaddyP]

Been a while but development continues. Since releasing node-red-contrib-ezo I have been working on a set of UI nodes for Node Red users to streamline a reef control setup. It's built on node-red-dashboard and styled in a consistent manner across the three nodes (input, output, probe). The bulk of the work lies in the 'output' node which offers set value output or an option to run a function on an interval.

Still some work to do in cleaning up the code, documentation, and further testing but users should see a ALPHA release by end of year. I'm hopeful since I've been using these on my (now wet) setup for over a week. Pic for proof...

Really starting to love the lack of visible plumbing in the display! Yes, the PID loop has been somewhat more complicated than needed, but overall it's working as well as could be expected. It seems I somehow designed the false bottom in a way that nearly balances the return flow and drain flow so the PID loop isn't quick enough to respond to fast changes. Will need to implement a faster moving actuator in a future version to allow better tuning on startup. Otherwise it does hold water level better than I had hoped.

False bottom is a 1/4" acrylic with 3/4" square support rods. Holes are drilled for both drain and return, in the future I'll have this custom laser cut to improve flow.

As far as the hardware, I did upgrade the RPi to SSD for stability and updated to Bulleye 64bit / NodeJS 16 to take advantage of increased memory. Widgetlords library needed to be rebuilt for 64bit so if anyone is interested here is the public build available until they start supporting 64bit systems:

MaddyTP/libwidgetlords_arm64

Install directions are the same as the 32bit version, just 'wget' the .deb file from my repo instead.

Final change was removing an older (v1) Kasa HS300 which was giving me issues. Not sure really what was wrong though I suspect it had to do with outdated hardware since the firmware wouldn't update. So now I'm rocking a nice little KP303 which is working as expected via node-red-contrib-tplink.

 

[Ranjib]

Been a while but development continues. Since releasing node-red-contrib-ezo I have been working on a set of UI nodes for Node Red users to streamline a reef control setup. It's built on node-red-dashboard and styled in a consistent manner across the three nodes (input, output, probe). The bulk of the work lies in the 'output' node which offers set value output or an option to run a function on an interval.

Still some work to do in cleaning up the code, documentation, and further testing but users should see a ALPHA release by end of year. I'm hopeful since I've been using these on my (now wet) setup for over a week. Pic for proof...

Really starting to love the lack of visible plumbing in the display! Yes, the PID loop has been somewhat more complicated than needed, but overall it's working as well as could be expected. It seems I somehow designed the false bottom in a way that nearly balances the return flow and drain flow so the PID loop isn't quick enough to respond to fast changes. Will need to implement a faster moving actuator in a future version to allow better tuning on startup. Otherwise it does hold water level better than I had hoped.

False bottom is a 1/4" acrylic with 3/4" square support rods. Holes are drilled for both drain and return, in the future I'll have this custom laser cut to improve flow.

As far as the hardware, I did upgrade the RPi to SSD for stability and updated to Bulleye 64bit / NodeJS 16 to take advantage of increased memory. Widgetlords library needed to be rebuilt for 64bit so if anyone is interested here is the public build available until they start supporting 64bit systems:

MaddyTP/libwidgetlords_arm64

Install directions are the same as the 32bit version, just 'wget' the .deb file from my repo instead.

Final change was removing an older (v1) Kasa HS300 which was giving me issues. Not sure really what was wrong though I suspect it had to do with outdated hardware since the firmware wouldn't update. So now I'm rocking a nice little KP303 which is working as expected via node-red-contrib-tplink.

Looks awesome

 

[MaddyP]

Looks awesome

Thanks Ranjib!

 

[MaddyP]

#MODS - would it be possible to merge this thread into my main build thread? I thought it would be easier to maintain the info in two different threads but I was wrong.

Main build thread: https://www.reef2reef.com/threads/maddyps-12g-long-node-red-nano-peninsula.549459/

 

[FischAutoTechGarten]

Maddy,
This setup is so nice and compact. All of my electronics live on a charcuterie board along the side wall of the fishnook.
Super high quality. Really looking forward to seeing the entire system functioning.... (just fascinating the way you are introducing the water!)

 

[MaddyP]

Maddy,
This setup is so nice and compact. All of my electronics live on a charcuterie board along the side wall of the fishnook.
Super high quality. Really looking forward to seeing the entire system functioning.... (just fascinating the way you are introducing the water!)

Thanks! Actually, the system is up an running over in my build thread:

Nano Build - MaddyP's 12G Long - Node-Red Nano Peninsula

Fellow Reefers, lend me your minds! I have decided to embark on a rather unconventional mission, though I have some doubts as to how successful such a system will be. As such, I thought it wise to consult the community for additional ideas. The primary goal for this build is to create a nano...

www.reef2reef.com

I did change up the PID loop a bit from the original plan. It worked well with the modulating ball valve as the control but every few minutes it needed to adjust slightly. So, instead of rely on that piece of equipment which may not be rated for continuous duty (although specs say it is) I adjusted the loop to be controlled by the return pump. Now the return varies slightly in output to compensate for variance in display level. Much more stable now with the ball valve acting as a safety in case of power failure or PID loop failure.

And the Node-Red widgets are coming along. I'm on vacation until January so hopefully the public will see a release before then.

 

[MaddyP]

PID loop is stable after switching the control over to the pump. Holding within a percentage point (tank volume) with the pump varying +/- 5% to maintain stability.

Also, development of these nodes is nearly complete. I'll start working through documentation today with the hope of publishing this weekend.

 

[MaddyP]

Text alerts are live! It's setup to keep track of all active alarms as shown in the third text.

 

[MaddyP]

More progress! Writing values to an InfluxDB database on my network for long term data storage. Now I can visualize trends over longer time periods easily. This is 48 hours of history loaded from InfluxDB when opening the tab.

The flow isn't overly complicated either:

Eventually I'll get this going for all my inputs / outputs so I can see trends.

 

[MaddyP]

It's been a lot of work these last few days, but the UI nodes are published!

GitHub - MaddyTP/node-red-contrib-ui-reef

Contribute to MaddyTP/node-red-contrib-ui-reef development by creating an account on GitHub.

github.com

I have a few refinements in mind so look forward to future updates!

 

[BTBR]

Hello All, I wondered if anyone could possible help. I have two atlas sensors O2 and CO2 and trying to send the info to Influxdb. I have the information in node-red from MQTT broker, but can't for the life of me work out how to format it for influx. I've tried to use your atlas node but nothing coming out of that at all.