Going to next level of Aquarium Automation...who's with me?

Hi,

thank you for taking the time out and replying, i have had full luck with all the automations from drain pumps (relays with level float sensor) to fill pumps(relays with level float sensor) even putting in flow sensors to calculate amount of water flowing in and out of the tanks.

Again the relays control all the important functions like lights fans heater chiller humidifier connected with corresponding automations.

the problem when i get stuck with is again pH and EC i am even ready to spend for tentacle shield and stamps by atlas scientific but then again i am no coder i need something which tells me how to connect, will go over again with your recommendations.

i have scoped now the tentacle shield and the example library is pretty easy to code on arduino and run any idea how we can get feed from sensor connected to UNO on I2C to hassio ?

Thankyou again

Hi @Gagan_Kochar

I would urge you to check out reef-pi - there is a tutorial on how to integrate the atlas scientific pH probe. The info from Reef-Pi is then available via API, which can be easily pulled into HomeAssistant as a sensor. Even if you only use it for getting pH readings, it will be by far the easiest way to grab that data, as you won’t really have to muck about with code.

You can also look through the giant Reef2Reef thread to see how other folks are getting pH readings with it.

The Atlas probe is too pricey for my little nano setup so I’ve just integrated a Google spreadsheet where I update dropper tests. You can read more about my setup on my Reef2Reef thread, which is a mixture of Reef-Pi and HomeAssistant control.

Just for kicks, here’s what mine looks like lately:

2 Likes

Thank you , for the link to reefpi going to check this out also had a email conversation with atlas scientific they say they are currently working on the code for mqtt as almost everyday they are getting requests the guy said almost 2 weeks and it will be done. so looking forward for that also,

can you also share how you used API settings from reefpi to HASS your system seems to reporting all the values needed

many thanks

1 Like

Good to know about the MQTT! A much needed option.

The sensors and controls that go to Reef-pi are just Rest Sensors. For different sensors, it’s just the “resource” link that changes.

The sensor.yaml entry for getting the water temp look like this:

- platform: rest
  name: ReefControlPiTemp
  username: !secret reefcontrolpi_username
  password: !secret reefcontrolpi_password
  authentication: basic
  resource: http://reefcontrolpi.local/api/tcs/1/usage
  headers:
      Connection: keep-alive
      content-type: application/json
      Referer: http://reefcontrolpi.local/
      Cookie: !secret reefcontrolpi_cookie
  value_template: '{{ value_json.current[-1].temperature | round(2) }}'
  unit_of_measurement: '°F'

My entire (giant) HomeAssistant config is on github here if you want to see more.

1 Like

@sfgabe thank you for pointing me to your github page, I think i will now be able to get to where i want will keep posted how my project goes

thanks again

1 Like

I have released a Swimmig Pool Automation System based on raspberry pi + HA, that have some similarities with this project. Maybe people here can get or propose ideas.
I use Atlas Scientific EZO boards and I have a custom-component to support all of them (pH, ORP, Dissolved Oxigen and Conductivity…). Only pH and ORP has been tested, and only UART connection is supported (no I2C).

Thanks

Thnaks

1 Like

Hi sfgabe, how are you storing the cookie details in your secrets file? I tried and it complains about tabs in the cookie.

1 Like

As far as I can see there shouldn’t be any tabs in the cookie, you might want to check for a copy/paste error. Here’s what I have in secrets.yaml:

reefcontrolpi_cookie: "auth=BIGSTRINGOFNUMBERSANDLETTERS="

Thanks for that. I didn’t have the auth= in front of the cookie. It’s now working.

1 Like

@sfgabe thanks for posting your entire HA config online. I still need to clean up mine & get mine posted likewise, and is on the list of things to do.

One thing I learned from your setup was the whole Janet speech engine. Ref URL for those who, like me, also missed that memo about Janet:

I am currently using Google TTS via all my remote Pi boxes via the speaker output. The core HA instance sends texts to say out to the Pi boxes via MQTT, and TTS conversion happens on each Pi. I’ve also been very surprised and pleased how “in sync” all the speakers sound across the house, despite different system loads on each Pi.

How is Janet working out for you? By any chance do you have some videos or audio recordings of how it sounds? Any implementation tips to watch out for? I think I may give this a try myself.

And again, thanks!

1 Like

@cowboy ha just in time for the final season! It would be especially cute to get her to give aquarium updates with fish facts, etc.

Janet (the Project you linked to) was great, though I think the latest google TTS changes on version (97.2) messed something up on my system, so she’s been troublingly quiet since I upgraded. I’m planning to look into this week, if I get anywhere I’ll post on the Janet page.

The code itself, with all the randomized response macros have been useful for other parts of templating, so it’s a good reference doc anyway.

Voices are from the Google Translate source, so you can pick any of these: https://cloud.google.com/text-to-speech/docs/voices - IMO “en-US-Wavenet-F” sounds the most Janet-like. You used to define the voice in the config.yaml file, but I’m not sure if that’s correct anymore.

1 Like

Hi All,

I have been trying to get pyseneye running on my pi on jesse but keep getting errors stating that libraries not available and the error below. Tried both python and python3 with and without sudo and same errors and pulling my hair out here. I have a device connected so it should just work.
All advice welcomed…

Alan

image

@pondguru,

Did you do a “pip install pyseneye” first?

Yes I did and I can see it loads correctly too…
Very strange.

Alan

Ahhhhh… I forgot about that. I think I forgot to tell @mcclown too. I remember now I had the same problem when I sat it up. There’s a typo in his instructions, but I had to get behind my RPI that has pyseneye installed (was at work earlier, thanks for your patience).

The first clue was in the error (python 3.7 gives more feedback, btw) here:

The second clue was in his own instructions:

In the instructions he says to “import SUDDevice” (with two "D"s), but on the very next line he sets “d = SUDevice()” … with just ONE “D” in SUDevice, not two.

So just to confirm, I went back to clue #1 and opened up “/srv/homeassistant/lib/python3.7/site-packages/pyseneye/sud.py” and looked for any instance of SUDDevice, and found none. But there was a class defined of SUDevice.

So the solution is, to change SUDDevice to SUDevice on the import line, and it all works. See screen cap:

I hope that helps you.

Note to @mcclown: maybe you can correct the typo in your documentation, pretty please? Thanks bro. :smiley:

BTW, welcome to the community, @pondguru. :slight_smile:

So running sudo python3 and dropping the second D it all works like a dream.

I can now create my own small python app to take readings and send them via mitt into emoncms and then off to my own home web pages.

Thanks for your help.

1 Like

It is done.

My 5 x Home Assistant node installation is, after much unexpected delay, is finally complete. This realises a goal I started envisioning more than 2 years ago right here on this forum. To realise the high availability / fail-over functional ability commonly seen in the GSM / Telecommunications provider sphere and / or like was originally embraced in the IBM System/4 Pi computer used in aviation and on the Space Shuttle for flight control systems.

This evolution of design came from me looking at commercial over the counter aquarium controllers, and comparing their functionality and design principles in relation to their costs. I hated everything I saw - and kept thinking “If I designed one of the GSM networks I used to work on, this way… I’d be fired.” Worse was the price tags associated with these commercial controllers, particularly when you looked at some of high market solutions and their associated accessories often referred to as “Breakout Boxes” or “Remote Probe boxes”. One vendor in particular only uses SPI communications to a remote break out box, which only contains components that if I built it, would cost me maybe 10-20 euros. But the branded commercial product cost over over 250 euros at the time I priced it. Worse, I saw the repurposing of USB type connectors as SPI cables potential future Human Failure errors just waiting to happen. (“Hey, can I charge my phone here?” ZAP)

Besides, I was already using an original RaspberryPi Model 1B since 2012 as my aquarium light controller. It ran my own code for controlling 10 x Neol branded Ethernet enabled PowerSwitch4 strips & 3 x APC MasterSwitch 8-socket power bars, in use around the house and on all my aquariums. And in May 2017, I thought combined with a RaspberryPi 3B, that RaspberryPi Model 1 would make a far better “Remote Probe Box” than anything I could by commercially. And, looking into the architecture of Home Assistant at the time, I realised I could create my own High Availability architecture using a network of RaspberryPi’s.

Most importantly, I turned the model of the commercial “dumb” Remote Breakout boxes on it’s head: Each place where I needed remote probes and sensors, would become it’s own redundant instance of Home Assistant. Dumb breakout boxes would become very Intelligent breakout boxes in my design. Further, having Ethernet enabled Powersockets vs. those attached directly to a Controller (like in commercial products) let me abstract Powerswitching out and away from the Pi-based controllers I made, allowing any remaining Pi standing in a failure situation, able to take over power switching duties, be it for heaters, water pumps, chemistry doses, mixers & stirrers, lights, etc.

I even could (and did) set it up that the RPI’s could reboot each other, attempting to get the failed node back online, if possible and necessary, without my presence or intervention required.

In a way, albeit a bit primitive, I was creating my very own locally installed HA Cloud. And it was still far more feature rich and reliable than any commercial controller I could find at the time.

And, just a couple of weeks after bringing the 3rd Pi (2x RPI3B and 1x RPI1B) online, a submerged aquarium heater suffered a leak failure causing my GFCI to trip after my wife and I had gone to bed, two floors upstairs from the aquariums. We never heard a thing, but the RPI on the 1rst floor could determine that it still could see the newly brought online RPI downstairs, but couldn’t see the RPI or Powerbars in the fish room, and sent out a message informing the GFCI / Circuitbreaker had probably tripped. And it saved the life of over 200 baby clownfish just a couple of months old. In the last 2 years, there have been about 6 different events similar to this, occurring, which HA has saved the day and my fishes lives.

This convinced me, and most importantly - my wife, of the value of what I’d sat out to achieve: High Availability and a design principle that eschews “Safe Mode of Failure, by Design”. I believe this itself is an expansion of the original design principle which Paulus Schoutsen set out to realise - your home automation should not stop working just because the Cloud or Internet Link stops working. In my case, I believe your automation should not stop working just because Home Assistant stops working.

Even if it cannot recover from the failure itself, as in the case of a mains power failure, it can still let me know about it. And further, remaining Home Assistant installs still running can take over, for what their able to see and control.

Eventually, performance requirements would dictate that I broke the Database (postgresql) to it’s own dedicated RPI3. And after a year of that, I migrated the core HA on an RPI and it’s dedicated DB server RPI both to dedicated VM’s on a NUC I picked up last year. And I migrated the RPI3 that serves as a GPS NTP server in the attic to an HA node, and deployed a RPI HA node on the first floor as well.

But the original Model 1B in the fish room always remained a “dumb GPIO slave” relative to all the other HA installed nodes through the rest of the house. This, despite the fact, it is the most physically complex RPI in the house.

Until yesterday. Yesterday I spent the day swapping it out & debugging a few glitches in the pre-configured drop-in replacement, which contained a pre-customized installation of HA, which I’d worked on in previous days. And at 5:34pm yesterday, my 5-HA node dream of a system came online. And thanks to @mcclown who provided the code to make Seneye work on RPI’s - now I can finally plug my Seneyes straight into an RPI in my fish room - without a Seneye SWS or a Windows computer running Seneye SCA application.

And this new RPI can take over heating control and critical functions, in the event the fish room were to ever find itself in the strange and unique position that it was the only mains circuit with 220V power, while the rest of the house was dark. Which is exactly what is going to happen in the coming months when they come to replace our mains power electrical box. :slight_smile:

All of this high availably and safe failure design principles price tag came at less than the cost of two of those “Breakout Boxes” ( SPI bridges ) available from expensive commercial aquarium controller companies. Minus my own labor writing the code & building the hardware around it all - but that’s the fun part. :smiley:

Many thanks to everyone, from Paulus Schoutsen on downwards, who’s contributed to Home Assistant in some way, making Home Assistant the most awesome home and aquarium automation products out there. I bet I could use it to launch missiles & control power planets reliably, even. I’m even asking myself “What new problems can I solve with HA?” :smiley:

Epic Home Assistant is truly epic.

6 Likes

Very neat. You mention you couldn’t survive a mains failure. Considering how much it sounds like you have invested, could you maintain some low amount of functionally and power it via UPS? I’m thinking like a simple blubber to keep some minimal amount of oxygen in the most important/expensive tank.

I’ve helped design a number of pieces of telecom equipment, and while we must survive single point faults, we aren’t typically required to survive two simultaneous faults. But sometimes it doesn’t cost a lot more to design it so that you could survive certain dual faults.

Finally, have you verified that your systems boot and operates everything at a minimal level when the internet is down? I’ve noticed some strange things sometimes if the internet is down when I reboot, but haven’t had time to dig in.

Good questions. And yes, I thought early on about UPS Systems, but decided against beginning there for the following reasons:

1.) UPSes don’t address / solve all possible problems in terms of High Availability.
2.) I’ve seen my share of “silent failures” with UPSes; they work great, until they don’t.
3.) The majority (read: all) of my mains power failures have been local (circuit breakers, GFCIs, etc.)
4.) Because of my home location’s on the electrical grid (very Centre of The Hague, Netherlands) and insider information (a friend who works in cybersecurity at the electric energy producer) I know we are at very, very low risk of this particular power company grid failure.

Risk wise, I am at a measurable higher risk of a Network Switch failure than Power Grid failure. BTW, I use enterprise Cisco switches but have seen it already more times that one of the power supplies in a network switch will fail at 5am long before our power grid actually goes out. A UPS wouldn’t address that, but a HA construction of Home Assistant does.

Further, when I started this, I realised, I could either BUY an aquarium controller (at a few thousand total price, at the very least) and a small UPS, or try to build my own controller and re-allocate those funds from controller to a much bigger UPS, or multiple UPSes. That is still the plan. Maybe we’ll even get a generator instead now. :smiley:

We do have dual Internet uplinks (DSL and Cable) so if one link goes down, it’s not a problem. But to answer your question, yes, I’ve noticed UI issues in HA when the Internet isn’t available. We had this when our Network Firewall’s hardware died last summer (blown caps). This is because certain elements of the HA interface still use the Internet Cloud services - if you use those features, like the historical graphs component. I’d much prefer to have some of this local rather than Cloud based, as I think that would better embody Paulus Schoutsen’s original idea. The solution to this, is use as little of those features as possible, if that’s a risk. If you do use it, have it setup in a way you can disable it in a pinch should that type of risk be realised.

Edited to add: UPSes have their place in a High Availability solution / architecture, but they should only be a component of it, not a single point of failure themselves.