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. 
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?
I’m using the Seneye Marine Sensor together with the Seneye component for Home Assistant that @mcclown was so kind to create and share with us. 
So I’m a bit late with this, but I’d like to wish everyone a happy new year and best wishes for 2020!
This coming May of this year, will mark 3 years I’ve been using HA to manage all my aquariums and home, and looking back at the number of times over those years and thinking about all the disasters alone that HA has saved my aquariums from, it is truly amazing. And then throw in all the extra time I have now reclaimed (think Automated Water Changes, remotely topping off the Sump with Salt Water when I’m in the next room vacuuming the sand in the display tanks, programming auto-dosers, etc.) - I become literally almost overwhelmed (in a good way) at what an excellent product Home Assistant really is.
And on that note, I’d like to especially thank all the fellow contributors who’ve joined the effort and shared their code, configuration files and build plans back into the project. I remain very appreciative of you and I can’t wait to see what we all can come up with in 2020.
And on that note - for those that aren’t following the thread about using Home Assistant as an aquarium doser (or hydroponics doser), check out @Twinsen68 brilliant contribution. He’s taken my original idea and created his own 4 channel reef dosing solution from scratch & is working on a calibration function. w00t!
Cheers!
2 Likes
Glad this is still going!
1 Like
Sorry, my initial reply to you had you confused with mcclown. Since corrected once I saw my mistake.
Yes, indeed, very much.
How’s your setup going?
I was familiar with Reef-Pi when I started this project, but at that time, it appeared that development had kind of stalled as a project. It’s since seemed to pick up steam again, but I don’t see anything gained from switching from HA to ReefPi now, as I now have HA doing everything that Reef Pi can do, and more.
Further, in my humble opinion, Reef-Pi, like the Arduino based RoboTank, are not exactly scalable to the degree HA is. For the person with just one or two aquariums, ReefPi and Robotank are probably fine. But I have a higher bar than most reefers with coral farming & fish breeding operations going on here since 2007.
At any given time, I may have up to 12 aquariums running or more. And they are not all located in the same room as each other. So I needed a more economically “enterprise-like” scalable solution. For instance - how many switched sockets does the ReefPi control?
Also, as stated in my original post discussing build requirements, I wanted an extreme level of high availability / redundancy. Microcontrollers (Arduino/ESP in our case) are typically really robust but there’s only so much one can do in terms of high-availability and redundancy with them. Sure, you can link ReefPi or RoboTank to HA and raise alarms via HomeAssistant if your aquarium controller stops responding, but that doesn’t do me a lot of good if I’m on a business trip to Romania or India.
I wanted a level of protection against even the controller crashing or failing. Which is why I went the route of multiple RPI’s running HA instead.
For reasons of high availability, redundancy and scalability, I wanted to abstract out everything from Temp probes to Switched PowerSockets. This way, if my primary instance of HA were to crash while I was away, another RPI could jump in and take over control of the switched power sockets of the ReefDosers, or the Main System Circulation pump, Lights, etc. Or if the RPI in the fish room which has the temp probe in the sump for heater control were to crash or fail, the main HA instance upstairs will switch over to using the Temp probes from the RPI in the living room. In fact, this level of redundancy using HA is pretty brain dead easy to setup.
I have 84+ switched sockets controlled already by Home Assistant. If those related to the aquariums (28, I think) were hard soldered to a ReefPi or Robotank… I’d lose the redundancy / high availability control of those sockets if the ReefPi / Robotank glitches out and locked up. Excuse the pun, but they’d be “dead in the water.”
This is why for awhile, I used to call my setup System/4 Pi. Not because it was based on RaspberryPi’s but because System/4 Pi was a special IBM computer used for Flight Avionics and even the Space Shuttle (my uncle worked on the integration of System4/Pi on the Space Shuttle) designed for robust fail-over. It was based on 5 computers that were all checking and monitoring each other as well as responsible for the flight and navigation operations.
I’ve since changed the name to a tribute to the movie WarGames (my wife’s request) and it’s now called WOPR - Water Operations Planned Response - aka Joshua. But my design goals of System/4 Pi-like redundancy lives on.
Additional benefits of my approach - is for my wife. She doesn’t have to learn yet another GUI interface. She can just go to the “Aquarium” tab of Home Assistant and take total control of the aquarium because she’s already using Home Assistant for so many other things in the house. Sure, once again, I could tie the Home Assistant interface to a Reef Pi or Robotank - but that’s just another level of unneeded complexity in the architecture.
However, the idea of a Hat for a RPI for WOPR (like the Leviathan, but geared more for HA-Reef) is something I’m currently working on. But it’s got a lower priority than some other features we realised no-one had taken up yet, which we decided to focus on first.
1 Like
And now for something completely different… a recycling project to make aquarium or home lighting out of old aquarium heaters. I’ve already recovered about 5-6 glass tubes from old and dead aquarium heaters, and was thinking about using them to make some ESP32 based Refuge lights by inserting LED grow strips into them. BigClive seems to have had a similar idea using other LEDs for home lighting.
Thought I’d share it for the inspiration value to your own home …and aquarium projects.
1 Like
So another “Lesson learned” I thought I’d share…
This is the first time I’ve used the Seneye Sensor with Home Assistant integration (Thanks @mcclown) on a 10 litre quarantine tank (not previously cycled - was dry before setup) with a fully grown clownfish in it. It’s only been in there a week and I started to notice something right away. The Seneye Ammonia sensor is so sensitive, it starts to register ammonia levels increasing almost immediately after the fish takes a dump. LOL. And what’s more, NH3 Ammonia levels also immediately take a downwards turn within just an hour or two of vacuuming up the fish pooh at the bottom of the 10 litre quarantine tank.
I figured this out by simply noticing the daily NH3 values rise in the graph displayed on my dashboard, and would go downstairs to check the fish & would find the pooh. After vacuuming the quarantine tank, I then began to notice that the NH3 values would almost immediately respond and start to drop again.
That means - I can totally create a Home Assistant Automation to play a TTS Voice notification through the house, informing me my fish has taken a pooh! LOL. This is hilarious, but practical as all heck for Quarantine / Hospital Tank management and helping our fish recover. Particularly if you had to setup your quarantine using a dry tank in a pinch and it wasn’t already established with nitrifying bacteria. In fact, that’s almost a serious game changer for running quarantine tanks.
Just thought I’d share that for what it’s worth.
1 Like