reef-pi :: An opensource reef tank controller based on Raspberry Pi.

[raketemensch]

You removed the2.5 install (including config) and did a clean install of 3.0 and re-setup all drivers and re-added all connections/equipment/macros/timers from scratch and it's still giving you the same issue?

If that indeed is the case, which would be very strange, I would try do a clean install and add things one by one to isolate what's giving you an issue. But I have a sneaky suspicion that some remnants of 2.5 is coming back to haunt your 3.0 install.

One of the things I love best about the pi is the SD card -- they're like old Nintendo cartridges, you can swap them back and forth endlessly.

When upgrading to a new version, or even making big changes, you can just use a new card to install/set up the new stuff, and if it fails, just boot off the old one.

 

[AbjectMaelstroM]

One of the things I love best about the pi is the SD card -- they're like old Nintendo cartridges, you can swap them back and forth endlessly.

When upgrading to a new version, or even making big changes, you can just use a new card to install/set up the new stuff, and if it fails, just boot off the old one.

That's my approach as well.

 

[burningbaal]

You have three different sensors detected , but none of them are the one that you had configured. Remind us about your setup? Any build thread I can look at?

allright, I was out of town for a couple days after I got it working again. I now see the temp sensors aren't working, so by ssh I can get this:
$ ls /sys/bus/w1/devices
0e-43c84a9b6197 0e-83c80a9b6193 0e-83c84a9b6197 w1_bus_master1

errors reported in the browser:
Dec 25 15:41:30
temperature sub-system. Failed to read sensor temp 1. Error:open /sys/bus/w1/devices/28-0119123f5374/w1_slave: no such file or directory

Dec 28 20:24:05
temperature sub-system. Failed to read sensor temp 1. Error:open /sys/bus/w1/devices/28-0119123d9588/w1_slave: no such file or directory

Dec 28 20:24:29
temperature sub-system. Failed to read sensor temp 2. Error:open /sys/bus/w1/devices/28-0119123f5374/w1_slave: no such file or directory

Dec 28 20:24:25
temperature sub-system. Failed to read sensor temp 3. Error:open /sys/bus/w1/devices/28-01191245a033/w1_slave: no such file or directory

it seems a bit random as to when it craps out. I'm thinking either it's bad sensors or bad soldering (on my part)...any other thoughts?

 

[burningbaal]

if anyone's interested, I've figured out how to remote into the raspi from (I think) anywhere in the world. You should be able to use realVNC or teamviewer (my preference for it's usability and my prior experience with it), probably others as well.

ssh into your pi (or use a keyboard/mouse), and:

1. sudo raspi-config
2. Interfacing options
3. vnc
4. enable
5. boot options (3)
6. Desktop/CLI (B1)
7. Desktop Autologin (B4)
8. Advanced Options (7)
9. Resolution (A5)
10. Pick one (I chose 1280x720 for now)
11. Finish & allow reboot

download realvnc or teamviewer:

1. sudo apt-get install realvnc-vnc-server
2. go with it :)

or download/unpackaged teamviewer

1. Make sure you have a teamviewer account (you should be able to get the free one unless your fish tank is a business...
2. `wget https://download.teamviewer.com/download/linux/teamviewer-host_armhf.deb`
3. `sudo dpkg -i teamviewer-host_armhf.deb`
4. `sudo apt --fix-broken install (if there were errors during number 2)`
5. `sudo teamviewer setup` (you'll log in to a teamviewer account
6. make sure you're set up on some other computer/tablet/etc for teamviewer with the same account as above
7. remote in!

That should be about it. If somebody else can try to repro this and finds some tweaks in what I wrote, please tell me and I'll edit this post!

 

[raketemensch]

allright, I was out of town for a couple days after I got it working again. I now see the temp sensors aren't working, so by ssh I can get this:
$ ls /sys/bus/w1/devices
0e-43c84a9b6197 0e-83c80a9b6193 0e-83c84a9b6197 w1_bus_master1

errors reported in the browser:
Dec 25 15:41:30
temperature sub-system. Failed to read sensor temp 1. Error:eek:pen /sys/bus/w1/devices/28-0119123f5374/w1_slave: no such file or directory

Dec 28 20:24:05
temperature sub-system. Failed to read sensor temp 1. Error:eek:pen /sys/bus/w1/devices/28-0119123d9588/w1_slave: no such file or directory

Dec 28 20:24:29
temperature sub-system. Failed to read sensor temp 2. Error:eek:pen /sys/bus/w1/devices/28-0119123f5374/w1_slave: no such file or directory

Dec 28 20:24:25
temperature sub-system. Failed to read sensor temp 3. Error:eek:pen /sys/bus/w1/devices/28-01191245a033/w1_slave: no such file or directory

it seems a bit random as to when it craps out. I'm thinking either it's bad sensors or bad soldering (on my part)...any other thoughts?

It seems to be checking the wrong deviceId

 

[Ranjib]

It seems to be checking the wrong deviceId

Yeah, the sensors configured in reef-pi are different from what has been detected. Either the sensor was changed or something is causing the sensors to have different address from before . If it’s later , check if it’s reproducible ( I.e. does those sensor Id remains same after reboot )

 

[Ranjib]

if anyone's interested, I've figured out how to remote into the raspi from (I think) anywhere in the world. You should be able to use realVNC or teamviewer (my preference for it's usability and my prior experience with it), probably others as well.

ssh into your pi (or use a keyboard/mouse), and:

1. sudo raspi-config
2. Interfacing options
3. vnc
4. enable
5. boot options (3)
6. Desktop/CLI (B1)
7. Desktop Autologin (B4)
8. Advanced Options (7)
9. Resolution (A5)
10. Pick one (I chose 1280x720 for now)
11. Finish & allow reboot

download realvnc or teamviewer:

1. sudo apt-get install realvnc-vnc-server
2. go with it :)

or download/unpackaged teamviewer

1. Make sure you have a teamviewer account (you should be able to get the free one unless your fish tank is a business...
2. `wget https://download.teamviewer.com/download/linux/teamviewer-host_armhf.deb`
3. `sudo dpkg -i teamviewer-host_armhf.deb`
4. `sudo apt --fix-broken install (if there were errors during number 2)`
5. `sudo teamviewer setup` (you'll log in to a teamviewer account
6. make sure you're set up on some other computer/tablet/etc for teamviewer with the same account as above
7. remote in!

That should be about it. If somebody else can try to repro this and finds some tweaks in what I wrote, please tell me and I'll edit this post!

I use google Wifi to selectively open reef-pi ( or ssh if needed) port for specific build and access the dashboard directly from normal browser , but using my static iP(Comcast) and the port that I have forwarded ( google WiFi) . It’s pretty light weight,

 

[marekd1]

Any possibility of expanding the I/O capacity by adding support for PCF8574 (I2C Digital I/O expander)?

 

[Ranjib]

Any possibility of expanding the I/O capacity by adding support for PCF8574 (I2C Digital I/O expander)?

Nothing planned. In 3.0 we introduced HAL (hardware abstraction layer), which makes this sort of things lot easier (can be shipped in a minor release without any major product changes).
On this specific functionality (i/o expansion), we had planned for mcp23017 support for 3.0, but later i de-prioritized it. This is bercause in 3.0, the pwm outputs can be used as standard digital i/o (relay control etc), which mean at least the output features can be offloaded to pca9685 (which are i2c and you can use multiple of them), thus leaving pi GPIO only for inlets/inputs. The newly added support for wifi/smart plugs also contributed to this.

Any specific reason for choosing pcf8574 over mcp23017 for i/o expansion?

 

[Ranjib]

Nothing planned. In 3.0 we introduced HAL (hardward abstraction layer), which makes this sort of things lot easier (can be shipped in a minor release without any major product changes).
On this specific functionality (i/o expansion), we had planned for mcp23017 support for 3.0, but later i de-prioritized it. This is bercause in 3.0, the pwm outputs can be used as standard digital i/o (relay control etc), which mean at least the output features can be offloaded to pca9685 (which are i2c and you can use multiple of them), thus leaving pi GPIO only for inlets/inputs. The newly added support for wifi/smart plugs also contributed to this.

Any specific reason for choosing pcf8574 over mcp23017 for i/o expansion?

i went through some spec, i think mcp23017 is a better choice. So, whenever we do add i/o expander support its likely going to be mcp23017 (also they are more ubiquitous i feel). Let us know if your thoughts,

 

[Ranjib]

Im playing with a lot of different battery-powered reef-pi options during the holidays (other than hacking on model railroad with reef-pi for my son). And wanted to share some insights,
The goal here is to come up with something that can allow reef-pi users to run minimal system (on demand or automatically) during power outage. As usual with reef-pi, the focus here to get something with frugal, affordable components.
My current thought process is to go with mobile power banks , they are cheap and can run multi-hour, easy to source and have different capacity options. Pair them with 5v airstone and submersible pumps (2W or 3Watts at max). Experiement and document the findings then proceed with 12V beefier/expensive power banks if need be.

With that I first used my wife's 4 year old 4600mAh power bank with a vanilla pi zero w. That ran around 13 hours. But i was not sure how the math works or if the powerbank if giving what its rated for after 4 years of use. So i then got a duracell 3300 mAh powerbank (as shown in the photo) and this one gives roughly 16 hours with wifi and reef-pi running . For some reason, i was expecting the pi will experience some kinda of undervoltage situation, and in anticipation i added undervoltage detector in reef-pi :-) . Its a common problem we encounter in some builds. But surprisingly it didnt trip, i.e. the power went out without lowering voltage (or at least thats what im concluding/deciphering).

None the less, i'll proceed testing with temp sensor, float switch, airstone , submersible pumps etc. And keep you all posted. I think this is pretty cool, it solves emergency backup situation as well as portable controller think (i need that for my saltwater mixing use case). If nothing, the airstone and pump can be directly hooked up to the powerbank for maximum run time.

@Bigtrout @Michael Lane @theatrus and other with more electrical/electronics understanding, can you decipher anything from this data. Here are the key summary:
- 3300 mAh powebank with 5v output
- Pi zero w draws 100-140ma
- Runtime was16.3 hours

 

[raketemensch]

[EDIT] Yes, it is working, I see the values changing in daemon.log.

Will the ATO chart on the dashboard show activity for just an ATO trigger, or is pump triggering also required?

I've got a float switch hooked up to IO27 on the goby hat, but I'm not seeing any activity. It's just 2 wires, so I don't think it's possible to have them backwards...

 

[Ranjib]

[EDIT] Yes, it is working, I see the values changing in daemon.log.

Will the ATO chart on the dashboard show activity for just an ATO trigger, or is pump triggering also required?

I've got a float switch hooked up to IO27 on the goby hat, but I'm not seeing any activity. It's just 2 wires, so I don't think it's possible to have them backwards...

So this is sorted right? ML hats work with float switch?

 

[raketemensch]

So what do y'all use for wires for these XLR/JST connections? Got a good, cheap source?

So this is sorted right? ML hats work with float switch?

Well, I see it triggering in the log, but not showing up in the dash. I only have one relay right now, and it's running in my "production" tank, so I'm ordering a new one now. Not gonna mess with Prod :]

I also have a wifi power strip:

Amazon product

...but I don't think it's supported.

 

[Ranjib]

So what do y'all use for wires for these XLR/JST connections? Got a good, cheap source?



Well, I see it triggering in the log, but not showing up in the dash. I only have one relay right now, and it's running in my "production" tank, so I'm ordering a new one now. Not gonna mess with Prod :]

I also have a wifi power strip:

Amazon product

...but I don't think it's supported.

Nope. But it looks really cheap. If its good and theres documentation on how to control it, we can consider supporting this,

 

[raketemensch]

Nope. But it looks really cheap. If its good and theres documentation on how to control it, we can consider supporting this,

[edit] Nevermind, I misread.

 

[marekd1]

Nothing planned. In 3.0 we introduced HAL (hardware abstraction layer), which makes this sort of things lot easier (can be shipped in a minor release without any major product changes).
On this specific functionality (i/o expansion), we had planned for mcp23017 support for 3.0, but later i de-prioritized it. This is bercause in 3.0, the pwm outputs can be used as standard digital i/o (relay control etc), which mean at least the output features can be offloaded to pca9685 (which are i2c and you can use multiple of them), thus leaving pi GPIO only for inlets/inputs. The newly added support for wifi/smart plugs also contributed to this.

Any specific reason for choosing pcf8574 over mcp23017 for i/o expansion?

Thanks for the info. There is no direct reason to support pcf8574. Basically looking for more I/O control lines. Not knowing what is in plan for future updates/releases I was thinking that this would be easy as there are many prototyping boards already available with pcf8574. In any event mcp23017 is definitely higher capacity and then some.

Few questions if I may:

Is there some sort of listing that would identify planned devices to be supported in future releases?

When do you think mcp23017 support would be available?

 

[Ranjib]

Thanks for the info. There is no direct reason to support pcf8574. Basically looking for more I/O control lines. Not knowing what is in plan for future updates/releases I was thinking that this would be easy as there are many prototyping boards already available with pcf8574. In any event mcp23017 is definitely higher capacity and then some.

Few questions if I may:

Is there some sort of listing that would identify planned devices to be supported in future releases?

When do you think mcp23017 support would be available?

We dont have any planned devices list other than whats already in github issue tracker (mcp23017). I have plans to add support for humidity sensor. @dmolavi is working on DLI pro smart powerstrip driver (no promise).
From reef-pi project execution perspective, my preference has been things that are pragmatic, affordable, reef/marine grade and have been tested thoroughly. What is your target usecase anything specific you are looking for?

 

[marekd1]

We dont have any planned devices list other than whats already in github issue tracker (mcp23017). I have plans to add support for humidity sensor. @dmolavi is working on DLI pro smart powerstrip driver (no promise).
From reef-pi project execution perspective, my preference has been things that are pragmatic, affordable, reef/marine grade and have been tested thoroughly. What is your target usecase anything specific you are looking for?

I am very new to reef-pi so I am still exploring. Presently heavy vested in Arduino's and HomeSeer for my tank automation including sensory via Atlas Scientific stamps and bunch of custom built stuff.

I love on how reef-pi is open and assignable so I am definitely very interested in it.

Lets just say that I've only discovered it last week and already flipped my lights controllers from Storm-X to running all 3 fixtures with reef-pi. My custom build 6 channel dosser is next to convert to reef-pi control. Today I was playing with my EHIM feeder, striped the native controller, connected to the PWM and its working like a champ. So at this rate I think everything will be reef-pi controlled. The reef-pi really got me re-thinking everything related to my tank.

From my perspective doing the prototyping is okay but once I have a better picture as to what is supported I typically design custom PCB with all key functions that I will use. So this is why I am asking about the devices that are planned for the support.

As to my wish list, there are two things on top of my list from the hardware support perspective more I/O lines and second support for the Salinity and ORP for Atlas Scientific stamps. I read your response on the Salinity and ORP and agree that they should work just fine with current PH driver support but calibration will be definitely an issue. I am not sure what would be involved in adding the calibration options but if there was a way to pass commands for calibration from reef-pi from some sort of console then this in a way would solve the problem with all Atlas Scientific devices.

The next thing would be the MQTT support.

One observation as to the reef-pi options is that it would be nice if labels would be assignable and not hard coded.

I will give you example with my feeder testing. In order to make it work I had to use DOSER configuration option. This is fine from the function subset perspective but then the label on the Menu bar could not be changed to reflect say Feeder. So it would be nice if you could select the desired operational functions and assign devices Inlets, Outlets, Jacks, etc to a operational role. So just expand what you are already doing with Inlets, Outlets, Jacks but to the menu label.

Yes one could argue that there is nothing wrong with having Feeder function under Doser Menu but I am just one of these guys that like everything nice and tidy.

So perhaps some thought could be put in place as to ability to have this function

Other than that as I mentioned before Outstanding work on reef-pi !!!!!

Best Regards
Mark

 

[marekd1]

Not sure if you already have a device in mind for the humidity but here is what I've been using the BME280 for most of my HomeSeer stuff.

Its I2C very accurate and provides also temperature and barometric pressure in addition to humidity