Reef-PI and Home Assistant

[overmyhead]

Thank you for sharing a working solution. HA forums have a lot of good people just like R2R forums, and I knew it could be done I just didn't know how. I actually copied the above and got it working in my instance as well, might use this down the road.

Funny enough HA actually got me back into reefkeeping 3ish years ago, there was a long thread where someone was using HA exclusively to control multiple tanks. I decided shortly thereafter the reliability needed with a controller wasn't going to allow me to use HA (though it can be done) and I think what you have (both reefpi and HA) is a happy medium for both reliability and 'extras'

worst case scenario if your HA instance fails, automation doesn't run, etc is the sunrise/sunset stays the same as the day prior right?

That's correct. Reef-PI still controls everything. In this case, Home Assistant is only changing the sunrise and sunset times set within Reef-PI. If HA goes down, or I lose connection between the 2, then reef-pi still functions as it would if I didn't use HA.

 

[cryptodendrum]

Thank you for sharing a working solution. HA forums have a lot of good people just like R2R forums, and I knew it could be done I just didn't know how. I actually copied the above and got it working in my instance as well, might use this down the road.

Funny enough HA actually got me back into reefkeeping 3ish years ago, there was a long thread where someone was using HA exclusively to control multiple tanks. I decided shortly thereafter the reliability needed with a controller wasn't going to allow me to use HA (though it can be done) and I think what you have (both reefpi and HA) is a happy medium for both reliability and 'extras'

worst case scenario if your HA instance fails, automation doesn't run, etc is the sunrise/sunset stays the same as the day prior right?

Hi @jnvd3b! It's me, cowboy from the HA forum.

Yeah, that was my thread ( https://community.home-assistant.io/t/going-to-next-level-of-aquarium-automation-whos-with-me/ ), and I just stumbled across this one here now. Kinda funny now that I think about it, I never searched out Home Assistant on this forum, until today; silly me.

Thought I'd just follow on with a bit more info, if others were interested, about how and why I sat it up using just HA.

Before I even discovered Home Assistant, my original design goal was to achieve a high availability setup (Fail Safely by Design is a design principle) using the concept of remote breakout probe boxes as semi- or fully- redundant controllers as an economical evolution of the design of current controllers, as well as delivering scalability, with minimal complexity. Also, the idea "if it's good enough for the aquariums, isn't it good enough for the house?" also got tacked on towards my requirements list. A reason for this was that anything I choose, my wife would have to operate it on her own, in the event I got whacked by a bus or tram on my bike or something like that. To have a single unified interface and a common way of doing things for everything, made the most sense.
I was a month down the road into OpenHAB when I discovered HA. I didn't want to back up and start again on something different, but the founder of the project's ideas and commitment to privacy and security and the architecture model he followed impressed me as a former GSM cybersecurity guy. (And really glad now I did.)

For my High Availability aspect isn't based around replicating the exact same copy of Home Assistant on every node (like say a duplicate VM on another physical host); rather it's the service of Home Assistant that is Highly Available. The reason it's that way, is because every node is different physically. Different number of water/air temp probes, water level probes, buttons, Seneye's attached to it, etc. This is necessary because of the way my aquarium architecture is laid out. I have 3 Display tanks in the Living room and Dining room, and so at least three sets of water level sensors, and three water temp probes, as well as a humidty and air temp sensor. These tanks are connected by pipes under the floor to our semi-dedicated "fishroom" where the sump, the refuge (over the sump) and all my "working tanks" (breeder tanks, frag tanks, fish fry growout tanks, Quarantines, etc.) are located. Both my fishroom and display tanks also have their own powerbars. When I started with this, Sonoffs were just getting off the ground, but I already had Neol and APC Powerbars (old datacenter & GSM base station shutdowns / upgrades) which are network controllable, which is far more flexible than serial port controlled units. If the fishroom network switch is separated from the primary Home Assistant node by a switch failure in the middle of the night, leaving the Home Assistant node isolated - it will see it is isolated and initiate heater control with the last known temp values the primary node was using. (BTW, any node failure raises all sorts of alarms). I use the same approach with my networked Auto-Dosers to eliminate the dreaded "my auto-doser got stuck and dumped all my Calcium in at once!" nightmares. If they operate outside of set parameters, we hard power them off, if all else fails, and that can be triggered by any 3 different HA nodes. If the HA node in the fishroom crashes, which has the temp probes in the fishroom connected to it, the primary controlling node will switch to the temp probe on one of the display tanks. And same Fail Safely by Design principle again on Auto Top Up, which is a split-brain Kalkwasser / Reverse Osmosis setup on top of that: Dial in how much kalkwasser to dose as AutoTopUp over night, and it spreads it out _evenly_ over 12 hours. By day it switches to Reverse Osmosis for top up on sensor demand - to help balance and smooth the diurnal pH swings. But most importantly - no more ATO failures.

Fun fact: Just for aquariums alone, there's 5 Powerbars of 24 switched sockets & 2 Sonoffs dedicated just to the aquariums. 10 different aquarium lights are also controlled.
Total of all home / aquarium switched sockets is 60; and 54 [smart] lights.

By default (i.e. - all is running well) the primary controlling HA node is upstairs on the first floor (second floor in US terms), and since it has no sensors it runs on a Virtual Machine. And there's two more Pi based HA nodes on the second and third (third and fourth in US) floors (for door and window sensors for the house automation). All nodes are on powerbars / smart sockets themselves and can be hard rebooted by another node, should they crash / fall off the network. This happened a few times when the RaspberryPi's were still SDcard based, but at the start of this year, I upgraded all the Pi's to Samsung SSDs, and that hasn't been a problem anymore.

I'll include some screenshots as well. My dashboard tab is really custom formatted for my portrait oriented monitor I keep Home Assistant open on, but the really tall image gets scaled down too much for nice viewing, so I cut it in half, into two parts for better readability. The Dashboard is separate from the Controls tab, which are further grouped and hidden or revealed by the Control Panel buttons. Mainly to prevent "accidental" activation by wife, cats or myself when scrolling on an iPhone / iPad.

This is the node overview page. WOPR = Water Operations Planned Response a.k.a. Joshua. Yes, we named it after WarGames. My wife's idea, was that "it was the only computer movie star who didn't want to kill everyone, he just wanted to play a nice game of chess."

Also, the tab of Beachcams is an example of why I don't replicate whole exact duplicates of HA, and focus on the HA as a Service High Availability approach - there's no need to replicate 10 streaming beach/sunset cams to each node. That exists only on the primary node which is the VM instance of HA (and has the the RAM / CPU for streaming HD beachcams).

If you have questions or need help setting up HA as an aquarium controller, let me know, here or on my Home Assistant thread. I can try to help with ReefPi on the HA side of things, but don't know much about ReefPi itself.

Cheers

 

[overmyhead]

@Ranjib I am trying to get the current ATO state from reef-pi via api. However, i cannot get it to return the state. When I view the ato api in my browser I see no change when the sensor is in water or out. The sensor does turn on and off a device though so I know the sensor is working. Can you give me more info on how to get the current state?

 

[Ranjib]

@Ranjib I am trying to get the current ATO state from reef-pi via api. However, i cannot get it to return the state. When I view the ato api in my browser I see no change when the sensor is in water or out. The sensor does turn on and off a device though so I know the sensor is working. Can you give me more info on how to get the current state?

the current ato status (sensor on or off) is only emitted as metric (prometheus, mqtt, adafruit.io), and not available via api. API can provide usage data, which is the closest thing. We can add this in API, file a ticket if you want to test it out. For simple verification, you can always use the log, reef-pi will log the sensor status only every check interval

 

[overmyhead]

Thanks. I have not used MQTT before. I'm struggling to get it working but I will keep playing with it. I haven't had much time to sit down and try to understand it. I am open to testing it for you, however, I am not very good with this stuff so I may not be the best to test. I will help as I can though.

 

[sfgabe]

Sorry @overmyhead I just saw this now. I've been off this site for the last few months staying out of town. The good news is Reef-pi and HA kept the tanks running happily without me and with only minimal maintenance by my boyfriend.

It looks like you got everything going as you wanted it. Let me know if you still have any unanswered questions, I will keep an eye out this time!

 

[overmyhead]

Sorry @overmyhead I just saw this now. I've been off this site for the last few months staying out of town. The good news is Reef-pi and HA kept the tanks running happily without me and with only minimal maintenance by my boyfriend.

It looks like you got everything going as you wanted it. Let me know if you still have any unanswered questions, I will keep an eye out this time!

I've gotten most things figured out. Only thing I haven't is being able to get the status of my float sensor and optical sensor. I have mqtt setup and my broker is connecting to reef-pi but I have no idea what should be in the state_topic.

 

[Ranjib]

I've gotten most things figured out. Only thing I haven't is being able to get the status of my float sensor and optical sensor. I have mqtt setup and my broker is connecting to reef-pi but I have no idea what should be in the state_topic.

Ato name should be the topic

 

[sfgabe]

Ato name should be the topic

I've gotten most things figured out. Only thing I haven't is being able to get the status of my float sensor and optical sensor. I have mqtt setup and my broker is connecting to reef-pi but I have no idea what should be in the state_topic.

It's a bit confusing because I've noticed there's some more to the naming - mine is named ATO Float in Reef-pi and MQTT is sent over on "ato_float_state" and "ato_float_usage". If you're able to ssh into HA you can run:

mosquitto_sub -v -h ha-or-whatever-broker-address.local -p 1883 -t '#'

That will get you the "fire hose" of everything MQTT is getting on which topics. The result will either be a 1 or 0.

 

[overmyhead]

It's a bit confusing because I've noticed there's some more to the naming - mine is named ATO Float in Reef-pi and MQTT is sent over on "ato_float_state" and "ato_float_usage". If you're able to ssh into HA you can run:

mosquitto_sub -v -h ha-or-whatever-broker-address.local -p 1883 -t '#'

That will get you the "fire hose" of everything MQTT is getting on which topics. The result will either be a 1 or 0.

@sfgabe and @Ranjib Thanks for your help. Combining ranjib's response with with sfgabe's code from his thread i was able to get it working. As sfgabe mentioned, it required "ato" before the name and "state" after which returns a 0 or 1.

 

[Ranjib]

It's a bit confusing because I've noticed there's some more to the naming - mine is named ATO Float in Reef-pi and MQTT is sent over on "ato_float_state" and "ato_float_usage". If you're able to ssh into HA you can run:

mosquitto_sub -v -h ha-or-whatever-broker-address.local -p 1883 -t '#'

That will get you the "fire hose" of everything MQTT is getting on which topics. The result will either be a 1 or 0.

Yeah, MQTT emission is very new and I think we should improve the metric naming scheme. During the initial implementation, I designed it as just another metric backend, so its 1:1 mapping with all existing metrics. For atos, the state represent the current status of the float switch, while the usage indicates hourly pump run time. The names are created by concatenating the name of the entity and metric. Any suggestions?

 

[overmyhead]

@Ranjib Did the naming scheme for MQTT change. My float and optical sensors were both working perfectly. However, the last week or 2 home assistant is showing unknown for status and they no longer control my ATO.

 

[Ranjib]

@Ranjib Did the naming scheme for MQTT change. My float and optical sensors were both working perfectly. However, the last week or 2 home assistant is showing unknown for status and they no longer control my ATO.

Did you update reef-pi? There was an mqtt bug leading to painc, hence we have updated some parts of it, but i dont think of anything that would actually change the mqtt message or topic names.

 

[overmyhead]

Did you update reef-pi? There was an mqtt bug leading to painc, hence we have updated some parts of it, but i dont think of anything that would actually change the mqtt message or topic names.

I don't remember updating since I updated to 4.0 originally. I will troubleshoot some more once I get more time.

 

[overmyhead]

I don't remember updating since I updated to 4.0 originally. I will troubleshoot some more once I get more time.

I upgraded to 4.1 and the sensor are working again.