Feature Request: Option to start server with no installed probe

[pcollinson]

The temperature-machine server will not start on a reboot (or systemctl restart) if it cannot find an active probe installed in its hardware. If the local network contains clients, this means that their data is not logged and cannot be seen when the server's probe dies for some reason and the server is rebooted.

In my case, the probe on the server has tended to drop out (probably a connection issue, which I may have fixed - crossing fingers) and means that the whole system stops when this happens. I lose logging of clients and cannot see their values until I can fix the hardware problem.

Ideally the server needs a config option which allows me to tell it that I have a network of sensors, and the server should restart even if it cannot find a probe on its machine.

[tobyweston]

Agreed. We should do something here...

[AlistairFielden]

Not related to this request but sensor drop out was mentioned.

I have had issues with sensors dropping out. It seems worse on Pi3,4 rather than PiZero. It also appears to be worse on the server machine, I have resolved this by powering the the senors from GPIO3 (pin5) (sensors data in on GPIO4 (pin7) and GND on pin9 - these are next to each other). I then have a bit of python script (see below) that looks for a '28-*' folder in the /sys/... directory and if it's not there turns the power off briefly on GPIO3. This reboots the sensor. I've used 'crontab -e' to run the script every 10 minutes. This only works currently for single sensors but could be adapted.

Restart.py.txt
Crontab.txt

[pcollinson]

This is very helpful. I'll look into some re-wiring. It's good to know it's not just me...
Is GPIO3 high at boot?

BTW Cron could be one line
*/10 * * * * sudo python /home/pi/Restart.py
or
0,10,20,30,40,50 * * * * sudo python /home/pi/Restart.py

[AlistairFielden]

Yes GPIO3 is high at boot so no need to turn it on.
I’ll mod my crontab config, I’d not realised you could do that

[tobyweston]

Love it, this is awesome guys.

I feel like we should roll this into the main app so everyone benefits. We could also think about changing the add-on board design if it makes sense. Can you explain more about the wiring and how it makes a difference?

Do you noticed anything in the TM log when a sensor drops? It should report it (and if it doesn’t, it means it’s not doing the same as the python script check and that’d be the first step).

[pcollinson]

I've scoured the logs, but it says nothing. It just stops. The Python script fails too when it's like this. I've also tried adding the name of the device into the w1_driver using the manual hook. This appeared to work, but only lasted about 2 minutes.

Basically taking the power rail off, and putting it back was the only remedy I've found. So what Alistair has done is to use GPIO pin3 as the power feed to the probe rather than a 3.3v pin in the GPIO. What that means is that when things appear to break the little bit of Python recycles the power feed to the probe - which is enough to wake it up again. However, this will not be the way that most people wire this.

[tobyweston]

There's no difference in the power between the power GPIO pin and pin 3 then? The only difference is you can switch it off and on again?

What I don't get is why temperature-machine doesn't detect the missing file in the same way as the py script. It should error if the files not found and that should go into the log. I'll have to double check this...

[pcollinson]

The pin puts out 3.3v when high. Which is the same as any of the pins actually. The good thing is that by default the pin is high, so you don't need to turn it on at boot. I've put a print statement into my script - and it's worked once on one of my machines since I installed it. Regards -------------------------------------------------- Peter Collinson

…

On 18 Aug 2019, at 13:34, Toby ***@***.***> wrote: There's no difference in the power between the power GPIO pin and pin 3 then? The only difference is you can switch it off and on again? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#87?email_source=notifications&email_token=ACY3BGGWUKCKTG6AA46A43DQFE6UVA5CNFSM4HI5YFQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4Q7DUQ#issuecomment-522318290>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACY3BGBNCERGKFIHHHFTY4TQFE6UVANCNFSM4HI5YFQA>.