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

Ok so here is the quick and dirty for the 0-10v output for controllable DC pumps OR 0-10v Led dimmable drivers (such as many Meanwells)

The Home Assistant side is extremely easy since I already have MQTT up and running:

  - platform: mqtt
    name: VarioS Pump
    state_topic: "pumps/variospump/pump/status"
    command_topic: "pumps/variospump/pump/switch"
    brightness_state_topic: "pumps/variospump/brightness/status"
    brightness_command_topic: "pumps/variospump/brightness/set"
    brightness_scale: 4095
    retain: true

The sketch was more difficult since I wasn’t able to copy someone else’s project I had to come up with something that worked. (which I have never done before)

#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <Wire.h>
#include <Adafruit_MCP4725.h>
#Adafruit_MCP4725 dac1; // constructor
#Adafruit_MCP4725 dac2; // constructor

// Wifi: SSID and password
const char* WIFI_SSID = "redacted";
const char* WIFI_PASSWORD = "redacted";

// MQTT: ID, server IP, port, username and password
const PROGMEM char* MQTT_CLIENT_ID = "Aquarium Controller";
const PROGMEM char* MQTT_SERVER_IP = "redacted";
const PROGMEM uint16_t MQTT_SERVER_PORT = 1883;
const PROGMEM char* MQTT_USER = "redacted";
const PROGMEM char* MQTT_PASSWORD = "redacted";

// MQTT: topics
// brightness
const PROGMEM char* MQTT_LIGHT_BRIGHTNESS1_STATE_TOPIC = "pumps/variospump/brightness/status";
const PROGMEM char* MQTT_LIGHT_BRIGHTNESS1_COMMAND_TOPIC = "pumps/variospump/brightness/set";
const PROGMEM char* MQTT_LIGHT_BRIGHTNESS2_STATE_TOPIC = "pumps/gyrepump/brightness/status";
const PROGMEM char* MQTT_LIGHT_BRIGHTNESS2_COMMAND_TOPIC = "pumps/gyrepump/brightness/set";

WiFiClient wifiClient;
PubSubClient client(wifiClient);

// function called when a MQTT message arrived
void callback(char* topic, byte* payload, unsigned int length) {
  Serial.print("Message topic [");
  Serial.print("] ");
  payload[length] = '\0';
  String strPayload = String((char*)payload);
  int intPayload= strPayload.toInt();
  Serial.println(strPayload);   //serial output of HA input slider (mqtt light brightness)
  if (String(MQTT_LIGHT_BRIGHTNESS1_COMMAND_TOPIC).equals(topic)) {
  dac1.setVoltage(intPayload, false); // set DAC to payload value
  if (String(MQTT_LIGHT_BRIGHTNESS2_COMMAND_TOPIC).equals(topic)) {
  dac2.setVoltage(intPayload, false); // set DAC to payload value
  else {

void reconnect() {
  // Loop until we're reconnected
  while (!client.connected()) {
    Serial.print("INFO: Attempting MQTT connection...");
    // Attempt to connect
    if (client.connect(MQTT_CLIENT_ID, MQTT_USER, MQTT_PASSWORD)) {
      Serial.println("INFO: connected");
      // ... and resubscribe
    } else {
      Serial.print("ERROR: failed, rc=");
      Serial.println("DEBUG: try again in 5 seconds");
      // Wait 5 seconds before retrying

void setup() {
  // init the serial

  // init the DAC
  uint32_t dac_value; // Converts the hexadecimal to 0-4096
  dac1.begin(0x62); // The I2C Address: Run the I2C Scanner if you're not sure
  dac2.begin(0x63); // The I2C Address: Run the I2C Scanner if you're not sure
  dac1.setVoltage(4095, false); // 4095 is max, 0 is min; 0-5v range
  dac2.setVoltage(4095, false); // 4095 is max, 0 is min; 0-5v range

  // init the WiFi connection
  Serial.print("INFO: Connecting to ");

  while (WiFi.status() != WL_CONNECTED) {

  Serial.println("INFO: WiFi connected");
  Serial.print("INFO: IP address: ");

  // init the MQTT connection

void loop() {
  if (!client.connected()) {

Lastly for wiring I relied heavily on this nice writeup.

Came out on the breadboard as such:

Just wiring a NodeMCU in I2C to two DAC chips, then using an opamp to double the voltage so that it is 0-10 rather than 0-5.

And that’s about it. Under $20 total as I had some of the items laying around, but I do like the 8-channels your ‘Maxim’ option provides.

I am in no way saying this is the best, easiest, or cheapest option but I found very little on the topic and this is what I came up with…it works well but I am sure there are ways to do it with little to no extra hardware.


Do the 4 channels also read electricty usage or just the POW model? Sorry new to Sonoff but I think the energy monitoring would be handy on some items like pumps to make sure they are working (similar to the Apex energy bar) and if they become clogged, you could set an alert.

1 Like

If they have a 4 channel POW model, please direct me too it. I’m about to order multiple POW units this weekend. :slight_smile:

I dont think they do after looking into it further.
I think I’ll order one POW and see how well it works.

Well dang… I guess this means I’m gonna have to change all my Seneye slides out for new ones finally. Thanks for making more work for me @jnvd3b. :smiley: lol

Heads up tho… this is not via the SUDdriver yet. I had a good look at what you sent me, and I still see some problems blocking the long term use of that (particularly “filling up” until the Seneye has talked to the cloud).
I’ve also got to update my Seneye units from their current firmware… it’s too out of date to be using the SUDdriver method, but updating looked like it might require more time than I had planned for today. Once I get that done I’m going to look at it the SUDdriver method more and see if I can help figure out what / how to over come that.

In the meantime today, I sat down and made a temp work around… sort of an alternative way to get the same data through the Seneye API server.

1 Like

I’ll go setup a proper Git space for myself before too long… until now, copy and paste will have to work if you want this functionality. :wink:

If anyone uses it, please let me know how it works for you. And please share a Screenshot of your final solution on HA. :slight_smile:

# Seneye API Simple Sensor Parser - Copyright 2017 Kevin McPeake
# A simple web API request function and parser for retrieving Seneye Device Data readings from the Seneye API Server, and parsing them to static file locations for reading
# and processing of data by Home Assistant's Command Line Sensor function.  Just a quickly hacked up workaround for starting to get Seneye Data into Home Assistant.
# Instructions for installing and using.
# 1) Save this script to a file named 'seneye' for a single seneye device, or if multiple seneye devices are used, make individual copies of this file based on a naming convention
#    like "seneye-1, seneye-2, seneye-3" or "Seneye-reef, Seneye-Pond, Seneye-Fresh" or something similiar like that.
# 2) Save / copy this file to a directory where you'll be sure to include it in your backups of Home Assistant and Home Assistant's user has access rights to read and execute.  This
#    could be in /usr/bin or /usr/local/bin or ~/bin ... whatever works best for you.  It should only be writeable by root. And it's probably BEST if it's only readable and executable by
#    Home Assistant user account and nothing else, since it will be storing your Seneye Password details.
# 3) modify the 'sensor=' variable declaration to reflect the name of your Seneye.  I recommend if you have multiple sensors and copies of this executable script, each named
#    as described / suggested above (i.e.- Seneye-Reef, Seneye-Pond, etc) that you set this to reflect the suffix of that file name for consistancy. (i.e.- sensor=Reef ).
# 4) Change the [DEVICEID], the [USER-LOGIN] and [USER-PASSWORD] to reflect your true Seneye settings;
#     a) [DEVICEID] can be discovered using the Seneye Web Server or the Seneye Connect Application (Windows).  Go to "Device Info" and you can find the nummerical
#        DeviceID number listed there.
#     b) [USER-LOGIN] and [USER-PASSWORD] also should be changed to reflect the login details provided when you login to the Seneye Cloud Portal.
# 5) Run the script (or scripts) as the Home Assistent user that HA runs under to ensure it is working properly.  Check within the directory of ~homeassistant/seneye/[SENSOR-NAME]
#    You should see a listing of files all reflecting the filename for the values they contain.  If you configured multiple sensors correctly, you should have a different folder
#    within the 'seneye' folder, each reflecting the name you gave that sensor in the script, each folder containing the respective values for that sensor.
# 6) Add all the seneye scripts you created to a crontab entry that is set to execute every 10-15 minutes.
# 7) The files within the folder structure will update at the specified crontab intervals. Now all you have to do is create the appropriate 'Command Line Sensors' in Home Assistant
#    that reads the contents of the files.  An example follows:
#    sensor:
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/temperature_curr"
#        name: Reef Temp
#        unit_of_measurement: C
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/ph_curr"
#        name: Reef PH
#        unit_of_measurement: Ph
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/nh3_curr"
#        name: Reef NH3
#        unit_of_measurement: ppm
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/nh4_curr"
#        name: Reef NH4
#        unit_of_measurement: ppm
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/o2_curr"
#        name: Reef O2
#        unit_of_measurement: ppm
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/slide_expires"
#        name: Reef Slide Expires
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/slide_serial"
#        name: Reef Serial
#      - platform: command_line
#        command: "cat /home/homeassistant/seneye/reef/last_experiment"
#        name: Reef Last Test
# 8) And away you go.
# Additional notes:  Seneye claims their API server calls are Rate Limited.  What this Rate Limit is, I don't know (yet) and I didn't want Home Assistant to end up blacklisting
# my account because Home Assistant's restAPI Sensor function was calling (read: pounding) the Seneye API server relentlessly.   Further to that, Seneye's SCA and SWS solutions for
# uploading the Seneye data to the Seneye webservers only does this once every 30 minutes anyways.  So HA's relentlessly pounding on their webserver asking for updates every 30-60 seconds
# probably wouldn't be appreciated on either ends of the links - mine or theirs.
# As a temp solution, I decided to quickly jot out this simple bash script. I wrote it in Bourne shell because I could actually do that faster than in Python, however, I may go back and re-write a
# python implementation.  If someone else feels up to the job, please be my guest. :D
# For now, this was a quick workaround and wasn't my final stopping point.  My next real goal is to completely replace the SCA / SWS requirement & try to get a working USB based implementation
# of reading the Seneye data right off the Seneye. Someone else has already begun this, but it's not stable or long term reliable just yet.  Hopefully we can fix that in the coming weeks and months.
# But until then, this is a good workaround if one already has a SWS or SCA and would like to have a copy of the Seneye data imported into HA, without having to run another local isntall
# of NodeJS for Seneye Data Exchange.

# Change the name of individual sensor here.  This can be whatever you want. (Be sure to remove the "[" and "]" brackets from your entry.)
sensor=[SENSOR NAME]
mkdir -p ~/seneye/$sensor

# change [DEVICEID] and [userlogin] / [password] and be sure to remove the "[" and "]" from the URL string (they aren't needed) in the line below
wget --header='Accept:application/xml' "https://api.seneye.com/v1/devices/[DEVICEID]?IncludeState=1&user=[USER-LOGIN]&pwd=[USER-PASSWORD]" -O - > ~/seneye/$sensor/$sensor.xml

# Leave the rest of this alone, modification shouldn't be needed here.

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>....<\/id><description>//g' | sed 's/<\/description>.*$//g' > ~/seneye/$sensor/description
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<disconnected>//g' | sed 's/<\/disconnected>.*$//g' > ~/seneye/$sensor/disconnected
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<slide_serial>//g' | sed 's/<\/slide_serial>.*$//g' > ~/seneye/$sensor/slide_serial
date -d @`grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<slide_expires>//g' | sed 's/<\/slide_expires>.*$//g'` > ~/seneye/$sensor/slide_expires
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<out_of_water>//g' | sed 's/<\/out_of_water>.*$//g' > ~/seneye/$sensor/out_of_water
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<wrong_slide>//g' | sed 's/<\/wrong_slide>.*$//g' > ~/seneye/$sensor/wrong_slide
date -d @`grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<last_experiment>//g' | sed 's/<\/last_experiment>.*$//g'` > ~/seneye/$sensor/last_experiment

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<temperature>//g' | sed 's/<\/temperature>.*$//g' | sed 's/^<trend>//g' | sed 's/<\/trend>.*$//g' > ~/seneye/$sensor/temperature_trend
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<temperature>//g' | sed 's/<\/temperature>.*$//g' | sed 's/^.*<critical_in>//g' | sed 's/<\/critical_in>.*$//g' > ~/seneye/$sensor/temperature_critical_in
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<temperature>//g' | sed 's/<\/temperature>.*$//g' | sed 's/^.*<avg>//g' | sed 's/<\/avg>.*$//g' > ~/seneye/$sensor/temperature_avg
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<temperature>//g' | sed 's/<\/temperature>.*$//g' | sed 's/^.*<status>//g' | sed 's/<\/status>.*$//g' > ~/seneye/$sensor/temperature_status
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<temperature>//g' | sed 's/<\/temperature>.*$//g' | sed 's/^.*<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/temperature_curr

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<ph>//g' | sed 's/<\/ph>.*$//g' | sed 's/^<trend>//g' | sed 's/<\/trend>.*$//g' > ~/seneye/$sensor/ph_trend
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<ph>//g' | sed 's/<\/ph>.*$//g' | sed 's/^.*<critical_in>//g' | sed 's/<\/critical_in>.*$//g' > ~/seneye/$sensor/ph_critical_in
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<ph>//g' | sed 's/<\/ph>.*$//g' | sed 's/^.*<avg>//g' | sed 's/<\/avg>.*$//g' > ~/seneye/$sensor/ph_avg
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<ph>//g' | sed 's/<\/ph>.*$//g' | sed 's/^.*<status>//g' | sed 's/<\/status>.*$//g' > ~/seneye/$sensor/ph_status
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<ph>//g' | sed 's/<\/ph>.*$//g' | sed 's/^.*<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/ph_curr

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh3>//g' | sed 's/<\/nh3>.*$//g' | sed 's/^<trend>//g' | sed 's/<\/trend>.*$//g' > ~/seneye/$sensor/nh3_trend
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh3>//g' | sed 's/<\/nh3>.*$//g' | sed 's/^.*<critical_in>//g' | sed 's/<\/critical_in>.*$//g' > ~/seneye/$sensor/nh3_critical_in
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh3>//g' | sed 's/<\/nh3>.*$//g' | sed 's/^.*<avg>//g' | sed 's/<\/avg>.*$//g' > ~/seneye/$sensor/nh3_avg
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh3>//g' | sed 's/<\/nh3>.*$//g' | sed 's/^.*<status>//g' | sed 's/<\/status>.*$//g' > ~/seneye/$sensor/nh3_status
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh3>//g' | sed 's/<\/nh3>.*$//g' | sed 's/^.*<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/nh3_curr

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh4>//g' | sed 's/<\/nh4>.*$//g' | sed 's/^<trend>//g' | sed 's/<\/trend>.*$//g' > ~/seneye/$sensor/nh4_trend
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh4>//g' | sed 's/<\/nh4>.*$//g' | sed 's/^.*<critical_in>//g' | sed 's/<\/critical_in>.*$//g' > ~/seneye/$sensor/nh4_critical_in
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh4>//g' | sed 's/<\/nh4>.*$//g' | sed 's/^.*<avg>//g' | sed 's/<\/avg>.*$//g' > ~/seneye/$sensor/nh4_avg
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh4>//g' | sed 's/<\/nh4>.*$//g' | sed 's/^.*<status>//g' | sed 's/<\/status>.*$//g' > ~/seneye/$sensor/nh4_status
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<nh4>//g' | sed 's/<\/nh4>.*$//g' | sed 's/^.*<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/nh4_curr

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<o2>//g' | sed 's/<\/o2>.*$//g' | sed 's/^<trend>//g' | sed 's/<\/trend>.*$//g' > ~/seneye/$sensor/o2_trend
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<o2>//g' | sed 's/<\/o2>.*$//g' | sed 's/^.*<critical_in>//g' | sed 's/<\/critical_in>.*$//g' > ~/seneye/$sensor/o2_critical_in
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<o2>//g' | sed 's/<\/o2>.*$//g' | sed 's/^.*<avg>//g' | sed 's/<\/avg>.*$//g' > ~/seneye/$sensor/o2_avg
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<o2>//g' | sed 's/<\/o2>.*$//g' | sed 's/^.*<status>//g' | sed 's/<\/status>.*$//g' > ~/seneye/$sensor/o2_status
grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<o2>//g' | sed 's/<\/o2>.*$//g' | sed 's/^.*<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/o2_curr

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<lux>//g' | sed 's/<\/lux>.*$//g' | sed 's/^.*<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/lux_curr

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<par>//g' | sed 's/<\/par>.*$//g' | sed 's/^<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/par_curr

grep description ~/seneye/$sensor/$sensor.xml | sed 's/^<response><id>.*<kelvin>//g' | sed 's/<\/kelvin>.*$//g' | sed 's/^<curr>//g' | sed 's/<\/curr>.*$//g' > ~/seneye/$sensor/kelvin_curr
1 Like

They do not monitor power. That would be a handy feature though for sure.

Also with the SPI interface the Reef Angel uses would I be able to control everything via HA if I were able to connect it to a Pi? That would be a much more economical way to do this than buying the Reef Angel Star or a cloud wifi attachment.

Ciwyn I think that could be something to look into, but I don’t know off hand. I remember something about master/slave arrangement with SPI? Don’t know enough about SPI yet to be able to really tell you. (looks at @jnvd3b)

So yesterday evening, I sat around and killed a few too many hours trying to get just the right font look to create some nicely fitting icons for the Seneye values to be monitored. Looks a little more polished now, I think. :slight_smile:

Today, I focused on the pre-requisites to having a look at the LDE feature of Seneye 2.0 and the SUDdriver python development. But as expected a little, the process of upgrading 3 Seneye devices probably elevated my blood pressure a tad bit, and took over 4 hours after various updates & installer failures all had to be resolved. :confused:

I’ll save most of my gripes about the Seneye, but have to mention this one because it’s a tiny new problem I think maybe Home Assistant actually solves? In the past, Seneye used to only cease with the pushed Alert/Notification services after the 30 days expiration mark passed. Otherwise, you could still see what your pH and Free Ammonia values were just as easily as before. And the data was still recorded in the cloud and available on the initial dashboard when one logged into Seneye’s portal.

And I bought into this ecosystem under that understanding. They wouldn’t take responsibility for alerting me outside of the calibration range, but I could continue to use the slides out of the 30 day period without restriction and at my own risk. If it all went sideways, only I was to blame.

Case in point - I consider the use of Seneye monitor’s absolutely mandatory for Quarantine and Fish Fry and Baby tanks. However, in the case of my large multi-tank system, the use of a Seneye is more on the ‘luxury’ side of things. In almost 13 years, pH has hardly ever gone outside of 8.2-8.4. I have a calibrated pinpoint meter I ended up getting anyways with my Seneye to double check an erratic / malfunctioning slide or three. The last time I needed to run a Seneye Slide on my big tank was at the end of Summer when I setup a new standalone 200liter clownfish grow-out tank with the plan to merge it into the big system shortly later. And merging one of the Fry tanks too. Afterwards, I thought here’s an opportunity - as all systems became merged - I left the Seneyes in place to watch / observe the deviation that would occur in 3 slides in the same body of water (never wanted to just waste 3 slides on this experiment before). What’s been interesting is that at least 2 of the Seneye’s are showing generally the same deviation patterns just at increasingly further points respective of each other as times goes along. In contrast, to the Seneye with the highest pH value, that seems to just have gone full tilt and flat-lined.
(My pinpoint pH say’s I’m at 8.45. and I just threw in a new Seneye slide to soak last night. Just wanted to disclaim that I am not using 3 month expired slides to actually monitor my pH levels. lol. :wink:


I find it interesting, because it does confirm that generally speaking, one should replace and only use a calibrated slide. However, it also is refreshing to see, because it also re-affirms something I wasn’t too sure of in the beginning - how long does one have after the 30-day period until things go sideways. Useful to know incase you ever get caught out without slides for a week while waiting for the new order to come in - the slides do degrade after 30 days, but not “unexpectedly” and can be carried over beyond the 30 day period for a short while without concern.

But in Version 2.0 - it appears that those values on the Windows SCA application dashboard are simply blocked out with an icon that says Slide Expired! and doesn’t allow you to see those values. And going to the user-portal to see the data, at least on the Dashboard - the NH3 and Ph values are notably absent. Temp is there, water level is there, but NH3 and Ph aren’t. But if you drill down to the individual Seneye Sensor USB Device pages, and look in the data activity, it’s still recording data (contrary to information posted about SCA2.0 on their web page.)

And… fortunately, the data is still completely coming across the api.seneye.com website where my script I wrote the other day pulls the data from. Which, completely allows me to solve the “hidden values” from the Seneye Dashboard. I knew HA would already solve a few quirks about Seneye I didn’t like, didn’t expect them to throw a new one along the way. lol

I hate when I get the feeling a company is punishing it’s user/customer base.

Strange Seneye, Strange. Hooray HA!

PS - I laughed out loud the next morning when I re-read my initial post and saw that I had diligently redacted 3 month old expired Seneye serial numbers from my screenshot. You all may laugh now at my expense too. I am. :joy::joy:

Good stuff. You can set up slide expiration reminders in Ha now. :wink:

1 Like

That… my own customized pH and Ammonia Alarms - think wake me up in the bedroom upstairs while an Ammonia bloom in a fry tank holding hundreds of babies at 3am. Or just change the color of an LED lamp in the living room when an Alarm conditions is raised. We’re gonna make Seneye do a few things it’s never done before.

So if the api is working so well, is the SUD driver approach even needed? Is the LDE needed? I am toying with the idea of just wiring it to my htpc and being done with it.

The API works well, considering that it’s providing me info the Windows App and Portal don’t, it works better than those two. lol
But, with the API approach, you still have to run SCA on Windows or SWS. I’d really like to get of an aging Windows laptop that’s running only for my Seneye and nothing else, but I don’t want to buy their overprice version of a proprietary RaspberryPi (SWS).

When I saw the SUD driver required the upgrade to 2.0, before I upgrade past 1.3, let’s first try the API and see if data formats or anything changes between that and 2.0 on the API site. (that way I could at least deliver some version 1.3 compatibility if it did change, and as the road to version 2.0 is a one way ticket…)

I also thought, ‘who knows how long it’ll take to solve the SUD issues’, but getting API working first would let myself and others at least then start getting busy with automations and other ideas. I’m hoping ultimately, any information we get from API is at least the same (in principle) as the SUD solution, so anything made for the API in HA will just work with SUD once (and if) that support is achieved.

I thought LDE might be interesting in case someone (or myself) decides to get at the data, without having the Cloud in the Middle. And removing the hard link requirement to Internet / Cloud in order to function, is right in line with Home Assistant principles, isn’t it? :wink:

But already as it stands now, this is a big improvement with API, the way I see it. I can finally have HA tell when the Seneye SCA (or Windows itself) has just gone into Suspended Animation mode, and HA will finally be able to just kick that whole laptop into a reboot without me intervening. After 7 years with that & Seneye…ooooohhhh…happy days! LOL

But if you want to go SCA and API using the above approach, please be my guest. That’s why I shared it! :smiley:
Let me know if I can help you with anything, or if you need some help setting up the UI side of things.

Just noticed that I forgot to post the URL’s @jnvd3b found and sent me. :slight_smile:

Just a small update: I got detoured looking at Hass.IO and digging into the details of resinOS to decide if I want to upgrade to that or not…

So I finally decided against the Hass.IO path forward. The offering of resinOS as the base appeared at first glance to offer some really nice promise for future deployment options, particularly since my solution is based around a multi-node model. However, the discovery that the Hass.IO team saw fit to remove the traditional docker utils / commands as well as some expected resinOS functionality appeared to be a stumbling block, if not all downright blocking issue. After spending 24+ hours on reading up and becoming familiar with how to work within the resinOS environment, it was very frustrating to discover I couldn’t utilize a lot of the potential power it seems to contain.

So I decided to revisit Hass.IO another time later and install Hassbian for now. Perhaps there’s an alternative way of doing what I need and just need more time to figure out what it is, but will deal with that later.

Needless to say, after installing a fresh copy of HA 58.1 (hassbian) and porting my configuration over, I was both pleased to see some of the new functionality but horrified to find out how slugish HA has become since version 44.

Particularly watching my automations run and the huge lag that occurs between a pump coming on and an update to the status of that pump being reflected internally (input_boolean or just the switch state even.

Further, under version 44, the CPU load used to average around 0.40-0.60. Now it’s around 2.40. No errors are coming up in the HomeAssistant.Log so I need some time to hunt elsewhere, perhaps in something with the OS that’s included with Hassbian?

Oh yeah, it seems unable to display correctly on the iOS client now on my old iPad2. This is also very disappointing now too. :frowning:

Need time to investigate further…sigh

I’ve liked Hass.io but that’s actually my only experience with HA. Only been up and running since august.

So I’m trying to get my little temp probe project running with a pi zero W and have run into a stumbling block right out of the gate. I’m trying to set everything up headlessly because I don’t have the USB and HDMI adapters. I’m using this tutorial to do this: [https://www.losant.com/blog/getting-started-with-the-raspberry-pi-zero-w-without-a-monitor] which is pretty standard. Whenever I turn the pi on I don’t see an IP address for it anywhere on my network which makes it quite tough for me to ssh into it as I’m using putty and you prettymuch need the IP. The SSID and PW are correct so I don’t know what I’m missing…

Do your SSID and/or password have any spaces in it? Make sure both are surrounded in the “” quotes. If you’ve got a really long / complicated passphrase, try setting it to something simple and stupid quickly / briefly on both the AP and the hass.io config & try to connect with that. I’ve stumbled over some char’s not getting /escaped out properly in my setups in the past.

It might be coming up as a hotspot, try using your phone to scan for it and then connect with that, then see if you can figure out why it’s not working properly.