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

[GaryE]

No experience with non-official ones. However, are you looking at all models of Raspberry Pi? It doesn't have to be the latest, most powerful one. Reef-Pi runs just fine on the RPi 3 or even the Zero W.

As a test, I picked up an Orange Pi 2G-IOT ARM Cortex-A5 32bit. Useless...

It will run reefpi, however, there are too many issues and it chokes right out of the gate. No interface, no sensors, nothing..

And this thing is so painfully slow as to be not useful for much other than holding down a few sheets of paper on my desk. And I suspect it won't do that very well.

 

[bishoptf]

As a test, I picked up an Orange Pi 2G-IOT ARM Cortex-A5 32bit. Useless...

It will run reefpi, however, there are too many issues and it chokes right out of the gate. No interface, no sensors, nothing..

And this thing is so painfully slow as to be not useful for much other than holding down a few sheets of paper on my desk. And I suspect it won't do that very well.

Yeah I think the closest one that MAY work is the bannapi ones but then I am not sure they will run raspbian so its a big YMMV. I started poking around but IMHO unless I can load raspbian and configure it the same, using another distro MAY work but then you have to tweak all kinds of things...which is a major pain.

 

[Ranjib]

I was also looking for a decently priced x86, preferably sbc , with hardware interfaces (gpio , pwm ) . Still didn’t find anything that will do the job without significant sticker shock . Pi is still the best in class

 

[Dave's Reef]

It might be a little over kill but my new reef-pi is almost done. Over the years I have had a few SD cards fail so this time around I wanted to try out a SSD and see how that does

 

[bishoptf]

@Ranjib or anyone know how to fix the Kasa strips on a reboot to begin working without a reload of the reef-pi application? What I have found is that when you loose power or reboot, you have to go into configuration and perform a reload in order to sync back up with the Kasa strips, otherwise it's not able to connect. Is there something that we can delay on startup with reef-pi in order to get it working without manually having to reload?

Thanks :)

 

[bishoptf]

It might be a little over kill but my new reef-pi is almost done. Over the years I have had a few SD cards fail so this time around I wanted to try out a SSD and see how that does

@Dave's Reef I too used to have those issues and found that when I switched to High endurance SD cards I stopped having issues.

Like these -
Transcend
Sandisk
Samsung

I think the transcend MLC is the best but more $$, if you want even better you can find some that are using SLC but even more $$.

YMMV, just thought I would pass it along..:)

 

[Dave's Reef]

@Dave's Reef I too used to have those issues and found that when I switched to High endurance SD cards I stopped having issues.

Like these -
Transcend
Sandisk
Samsung

I think the transcend MLC is the best but more $$, if you want even better you can find some that are using SLC but even more $$.

YMMV, just thought I would pass it along..:)

Thanks for the reply I'm not computer expert I have never even heard of high endurance sd cards lol. Hopefully the SSD will do the trick no more SD card at all. If it doesn't ill definitely go back to using an SD card and will be giving a high endurance one a shot thanks

 

[GaryE]

I was also looking for a decently priced x86, preferably sbc , with hardware interfaces (gpio , pwm ) . Still didn’t find anything that will do the job without significant sticker shock . Pi is still the best in class

Im making pretty good progress with porting some of the functions over to Arduino, specifically ESP32 hardware.

I have a little work yet to do on building the json commands to send to the kaza api, but it's moving along. It would go a bit faster if I actually had a clue what I was doing with C/C++.

I was actually thinking of just using one ESP32 or ESP8266 for each function. Yes, the hardware cost can creep that way, however, if only doing one or two temp sensors and one or two lights, it should be pretty manageable.

As for UI, right now it'll be minimal to nonexistent. Everything for now will be configured prior to uploading to the device and output will be done thru a prometheus metrics export. I've gotten pretty good with that in the last few weeks. I have all sort of things in my house spitting out metrics to prometheus.

 

[bishoptf]

@Ranjib or anyone know how to fix the Kasa strips on a reboot to begin working without a reload of the reef-pi application? What I have found is that when you loose power or reboot, you have to go into configuration and perform a reload in order to sync back up with the Kasa strips, otherwise it's not able to connect. Is there something that we can delay on startup with reef-pi in order to get it working without manually having to reload?

Thanks :)

So I found my old post that discussed it, you had me add this to the systemd file:

After=network-online.target
Wants=network-online.target

But for some reason it was not found in the service file any longer, maybe an upgrade or something reset it to the default. Did you include that in the newer versions or is it still a manual input and is there a reason it's not added as a permanent fix? Just thought I would ask and see where it ended up.

Thanks

 

[Ranjib]

So I found my old post that discussed it, you had me add this to the systemd file:

After=network-online.target
Wants=network-online.target

But for some reason it was not found in the service file any longer, maybe an upgrade or something reset it to the default. Did you include that in the newer versions or is it still a manual input and is there a reason it's not added as a permanent fix? Just thought I would ask and see where it ended up.

Thanks

New install should not change existing systemd unit files.
we can’t make that network dependency as reef-pi can and should be able to run without network by default. As users add new drivers , they can change the startup or any other details accordingly . What would be awesome if we have that ability straight from reef-pi ui

 

[bishoptf]

New install should not change existing systemd unit files.
we can’t make that network dependency as reef-pi can and should be able to run without network by default. As users add new drivers , they can change the startup or any other details accordingly . What would be awesome if we have that ability straight from reef-pi ui

Yeah I guess I understand but it leaves the Kasa stuff kind of in a wonky state, not sure I agree that reef-pi should start up if networking is not available. I understand that it doesn't require it but if there is something wrong with the networking stack do I still want it to boot? Could it be possible to have reef-pi running and not be able to connect to it, something interesting to ponder. I also think leaving it up to users to edit systemd files probably is not the best answer either, maybe a compromise would be to have the system automatically do a reload after booting up and after a timeout period if the user is using any Kasa drivers.

Probably is a better way but maybe there is some easy solution that would work. :)

 

[Ranjib]

Yeah I guess I understand but it leaves the Kasa stuff kind of in a wonky state, not sure I agree that reef-pi should start up if networking is not available. I understand that it doesn't require it but if there is something wrong with the networking stack do I still want it to boot? Could it be possible to have reef-pi running and not be able to connect to it, something interesting to ponder. I also think leaving it up to users to edit systemd files probably is not the best answer either, maybe a compromise would be to have the system automatically do a reload after booting up and after a timeout period if the user is using any Kasa drivers.

Probably is a better way but maybe there is some easy solution that would work. :)

I think the default installation should always boot even if network stack is not up , as it’s designed to run without networking dependency, and this is the best way to make sure it continue to operate like that. stand-alone installation can always have physical display attached to it .
I can understand cases where user wants to wait for network, hence the systemd workaround for those cases. We can always think of sophisticated workarounds, but that means more dev work and more testing , and more customizability coming from that specific case. What I prefer is to keep the main software barebones and instead have distorts or specific type of builds that tunes the Linux user land accordingly,

 

[robsworld78]

I think the default installation should always boot even if network stack is not up , as it’s designed to run without networking dependency, and this is the best way to make sure it continue to operate like that. stand-alone installation can always have physical display attached to it .
I can understand cases where user wants to wait for network, hence the systemd workaround for those cases. We can always think of sophisticated workarounds, but that means more dev work and more testing , and more customizability coming from that specific case. What I prefer is to keep the main software barebones and instead have distorts or specific type of builds that tunes the Linux user land accordingly,

I agree reef-pi should run without a network by default, some use RTC and off grid and should be case. That could also put things at risk if it can't connect which is why I wouldn't use it period, then you're running with no controls until you fix it or it connects.

 

[bishoptf]

I think the default installation should always boot even if network stack is not up , as it’s designed to run without networking dependency, and this is the best way to make sure it continue to operate like that. stand-alone installation can always have physical display attached to it .
I can understand cases where user wants to wait for network, hence the systemd workaround for those cases. We can always think of sophisticated workarounds, but that means more dev work and more testing , and more customizability coming from that specific case. What I prefer is to keep the main software barebones and instead have distorts or specific type of builds that tunes the Linux user land accordingly,

I agree reef-pi should run without a network by default, some use RTC and off grid and should be case. That could also put things at risk if it can't connect which is why I wouldn't use it period, then you're running with no controls until you fix it or it connects.

I don't disagree but we are left with drivers that says they are supported yet on a reboot or power outage are not fully functional. I don't believe that is a good option either. Honestly I think the users that are using a reef-pi in stand alone mode with no network to be more of a minority than those using it with a network. IMHO it would be better to support the majority and have the stand alone users update the systemd file. As it is now reef-pi states that they support Kasa devices with drivers available but they are not fully supported as it is today and depending on what the user has off of the kasa strips will not be reachable until they logon and do a reload.

@Ranjib I guess I am the only one that sees this as an issue, I was hoping that there would be a solution that could be done after a reboot/power loss. I know we have to do a reload but is there anything else besides restarting reef-pi service that will get the Kasa strips working?

If this is the case and it remains I think somewhere it needs to be stated and maybe it is, that integration with the Kasa strips require this workaround. Maybe when you select the driver have some words printed in the default configuration screen that warns the user.

Just my .02... :)

 

[DWKDiver]

Ranjib

I found that calibrating the temp probe using the GO button on the pop up key pad gives error if value is not in a given range. If I use APPLY and not the GO button it seems to use the value given. This might be a UI issue. And I don't understand the GO value limits given at all. Can you explain? Thank you and nice work.

 

[DWKDiver]

I like the video at show also!

 

[Dave's Reef]

I don't disagree but we are left with drivers that says they are supported yet on a reboot or power outage are not fully functional. I don't believe that is a good option either. Honestly I think the users that are using a reef-pi in stand alone mode with no network to be more of a minority than those using it with a network. IMHO it would be better to support the majority and have the stand alone users update the systemd file. As it is now reef-pi states that they support Kasa devices with drivers available but they are not fully supported as it is today and depending on what the user has off of the kasa strips will not be reachable until they logon and do a reload.

@Ranjib I guess I am the only one that sees this as an issue, I was hoping that there would be a solution that could be done after a reboot/power loss. I know we have to do a reload but is there anything else besides restarting reef-pi service that will get the Kasa strips working?

If this is the case and it remains I think somewhere it needs to be stated and maybe it is, that integration with the Kasa strips require this workaround. Maybe when you select the driver have some words printed in the default configuration screen that warns the user.

Just my .02... :)

I agree with you I have a kasa strip and it's a pain in the butt I forgot about it or if we had a power flicker and I didn't know it doesn't work so I only use it for non essential things. Would it be possible to just dely reef-pi from booting up at startup like have it wait 30 seconds or so? Just a thought I am by no means a program nor do I know how any of that background stuff works

 

[robsworld78]

I don't disagree but we are left with drivers that says they are supported yet on a reboot or power outage are not fully functional. I don't believe that is a good option either. Honestly I think the users that are using a reef-pi in stand alone mode with no network to be more of a minority than those using it with a network. IMHO it would be better to support the majority and have the stand alone users update the systemd file. As it is now reef-pi states that they support Kasa devices with drivers available but they are not fully supported as it is today and depending on what the user has off of the kasa strips will not be reachable until they logon and do a reload.

@Ranjib I guess I am the only one that sees this as an issue, I was hoping that there would be a solution that could be done after a reboot/power loss. I know we have to do a reload but is there anything else besides restarting reef-pi service that will get the Kasa strips working?

If this is the case and it remains I think somewhere it needs to be stated and maybe it is, that integration with the Kasa strips require this workaround. Maybe when you select the driver have some words printed in the default configuration screen that warns the user.

Just my .02... :)

I hear you, just sounds risky to me not allowing reef-pi to start without a network connection.

 

[Dave's Reef]

I hear you, just sounds risky to me not allowing reef-pi to start without a network connection.

Is it possible to delay the start or have it start with out a network after a 30s or 1 minute? I do think it's good idea for it to run with network or not but could the start be delayed somehow?

 

[robsworld78]

Is it possible to delay the start or have it start with out a network after a 30s or 1 minute? I do think it's good idea for it to run with network or not but could the start be delayed somehow?

Just found this, it says network-online.target will time out after 90 seconds so it looks like I was fretting for nothing.

NetworkTarget