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

[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

www.freedesktop.org

 

[Dave's Reef]

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

NetworkTarget

www.freedesktop.org

So how I do I make mine do this cause now it looks for the kasa right away and ofcourse the pi has no network so it doesn't see it and I need to reboot?.
Sorry I'm a little slow on how all this works
Thanks

 

[robsworld78]

So how I do I make mine do this cause now it looks for the kasa right away and ofcourse the pi has no network so it doesn't see it and I need to reboot?.
Sorry I'm a little slow on how all this works
Thanks

You have to edit the service file from the SSH terminal. Do the following.

• Run the command sudo nano /lib/systemd/system/reef-pi.service to edit the file
• At the bottom add the following two lines.
  • After=network-online.target
    Wants=network-online.target
• Press CTRL + S to save
• Press CTRL + X to exit
• Run the command sudo reboot to reboot

Hopefully that works.

 

[bishoptf]

You have to edit the service file from the SSH terminal. Do the following.

• Run the command sudo nano /lib/systemd/system/reef-pi.service to edit the file
• At the bottom add the following two lines.
  • After=network-online.target
    Wants=network-online.target
• Press CTRL + S to save
• Press CTRL + X to exit
• Run the command sudo reboot to reboot

Hopefully that works.

Eh I prefer vi but nano will work

I would add those to command at the end of the unit section and not at the bottom. Here is what the file looks like now:

[Unit]
Description=raspberry pi based reef tank controller

[Service]
ExecStart=/usr/bin/reef-pi daemon -config /etc/reef-pi/config.yaml
WorkingDirectory=/var/lib/reef-pi
Restart=always
RestartSec=90
StartLimitInterval=400
StartLimitBurst=10

[Install]
WantedBy=multi-user.target

How I think you want it to look like:

[Unit]
Description=raspberry pi based reef tank controller
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/reef-pi daemon -config /etc/reef-pi/config.yaml
WorkingDirectory=/var/lib/reef-pi
Restart=always
RestartSec=90
StartLimitInterval=400
StartLimitBurst=10


[Install]
WantedBy=multi-user.target

You don't have to reboot just do this command and you will be good...

sudo systemctl daemon-reload

 

[Ranjib]

Working on this new version of float switch mount for ato . I have to readjust the old one for hight and width , for each of the tanks. This time I also added some pass through shapes for the water line. I have noticed they get wonky when not fixed properly , and the turning point develop kinks . Hopefully this will address it .

side view

top view

3D design file: https://www.thingiverse.com/thing:5316107

 

[bishoptf]

.

Working on this new version of float switch mount for ato . I have to readjust the old one for hight and width , for each of the tanks. This time I also added some pass through shapes for the water line. I have noticed they get wonky when not fixed properly , and the turning point develop kinks . Hopefully this will address it .

side view

top view

3D design file: https://www.thingiverse.com/thing:5316107

Yeah, I've not been happy with mine either, I need something more adjustable but thanks for sharing always looking for something new.

 

[GaryE]

Working on this new version of float switch mount for ato . I have to readjust the old one for hight and width , for each of the tanks. This time I also added some pass through shapes for the water line. I have noticed they get wonky when not fixed properly , and the turning point develop kinks . Hopefully this will address it .

side view

top view

3D design file: https://www.thingiverse.com/thing:5316107

I would have a 3d printer if I could figure out how to make things with a 3d Cad program... That stuff baffles me.

 

[GaryE]

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.

This may not sound that exciting to most (especially my Spousal Equivalent), but I have a KP303 on my desk with one outlet being repeatedly turned on and off by an ESP32. Turning on / off a single outlet Kaza device is not trivial, adding the 2 extra outlets on a strip increases the complexity. Having to identify the target relay with only knowing the ip address of the power strip is a task. (Im sure @Ranjib can relate) I was able to (with some help from Stack Overflow) make a function to encrypt the json string to send to the Kaza device..

I just need to integrate a temp sensor and the logic to monitor it and use what I have built here on my desk now to turn the thing on and off when the temps are outside the set parameter.

My test board is this Adafruit ESP32-S2 TFT Feather (https://www.adafruit.com/product/5300). I plan to use the TFT on it to display the current temp and status of the heater. Thinking just display the temp nice and large with 2 decimal places and color the background either green for not heating or red for heating. And since the ds18b20 is supported by ardiuno, should be a robust little temp controller.

 

[elysics]

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...

This is why a long while ago i was very adamant, maybe even rudely so, about wanting hardwired outlets and no wifi smart devices. I actually ran rather often into the situation where the network/router wasn't up.

And in that case, or if the pis network chip dies, or whatever, I'd rather have the pi continue operating the ato and dosers and alarms and stuff than shut all that down and wait for a network that might never come or only hours or days later, particularly if noone is home. Power outage situations/ running on backup power are another consideration.

I've got a better router now, and some smart plugs, but i still only give them noncritical devices to control like some unimportant pumps and other stuff unrelated to the tank.

I am not sure compromising reefpi by default for the sake of one driver for one particular device is a great idea, especially when people that have those can make their own choice to do that if they want.