@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
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. 
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. 
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.
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?”
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.
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.
Great to see the progress @cowboy
I wrote an article a few weeks ago saying that every software development team should have an aquarium. I wrote that aquarium automation is a good surrogate for the complex systems that companies deal with but with a much shorter feedback cycle. You have further confirmed this idea with this post. Here’s the article: https://medium.com/@mcclown_38611/motivating-your-dev-team-with-real-time-feedback-and-a-fish-tank-5a3a891cc0c1
1 Like
Actually, you got me thinking again about the UI issues if / when there is a complete Internet link failure and the GUI depends / expects Internet connectivity to render History Graphs and other eye candy, resulting in sluggishness of the UI. And to be honest, I don’t know why I didn’t implement it before - I have it already for another reason.
Fortunately, the History Graphs component doesn’t render anything until it’s viewed. If you try to view it without Internet connectivity, it can’t reach the Google API it needs and goes into Time-out-Land.
The solution may be just to make it “not viewable”, automatically.
I previously built a “Control Panel” pane that let me hide / unhide other panels on the Aquarium Interface - partly for safety, partly to clean up the Panel overload, as demonstrated here:
Here all the extra panels are turned off and not viewable. Things like heater control, pump control, etc. But in the next image, the Heater Control Panel is toggled on, and it becomes viewable.
I just have to set this up for all my history graphs, but instead of using an input_boolean for the toggle, I just have to automate it, based on the Internet connectivity status - which is already monitored by Home Assistant.
- alias: 'Heater Control Hide Panel'
initial_state: true
trigger:
- platform: state
entity_id: input_boolean.heater_control_panel
to: 'off'
- platform: homeassistant
event: start
action:
service: group.set_visibility
entity_id: group.heater_mgmt
data:
visible: False
- alias: 'Heater Control Show Panel'
initial_state: true
trigger:
platform: state
entity_id: input_boolean.heater_control_panel
to: 'on'
action:
service: group.set_visibility
entity_id: group.heater_mgmt
data:
visible: True
In my case, if it see’s both Internet Uplinks down - hide the panel, and that should prevent sluggishness, I think.
My previous fix was to restart the server with those groups manually commented out, but I somehow suspect this might be a more graceful and automatic fix to that problem. Will give it a try soon and let you know.
Interesting solution. I just reloaded my main page when the internet was down, and my iframes were hanging. I’m going to play with it more, but I might have to adopt something similar.
How did some of you get sensor readings for nitrate, nitrites, and ammonia? What kind of sensors are you using?