So I see work has already been done to support a 1-wire driver for reading 1-wire sensors. However I only see discussion of reading sensors, not writing to 1-wire i/o chips, such as DS2405 or DS2408. Obviously I need to dig deeper, and track to the cost to the original documentation, but has anyone implemented full i/o with the 1-wire bus using the onion, or are we only reading sensors so far?
Pretty cool...
I love the fact you use 1-wire sensors, I use 1-wire sensors every chance I get. I like to epoxy the sensors directly to refrigeration plumbing so I can track superheat and subcooling in multiple locations, and sprinkle them everywhere in the system for more visible process control... So thumbs up for that!
But you need to be sure to integrate a real hold-off timer, as short cycling the compressor can destroy it. It sounds like your duty cycle design may do this, but I can't be sure. And one source of short cycles can be power blinks caused by weather or substation switching, so hold-off time must be added to the startup of the unit after being powered off.
On compressors with internal thermal protection, you will overheat the compressor until the thermal protection trips, and the resulting delay "resolves" the issue, until you eventually wear out the thermal protection switch, then the compressor is shot. On units without thermal protection, you simply overheat the compressor until the windings melt, and the compressor is shot. It is critical that the compressor not try to turn on before the pressures equalize between the low and high side refrigerant circuits. So every time the compressor is turned off, it MUST stay off for some minimum amount of time, and this time varies system to system.
The PID control question is a completely different issue. PID's are great to prevent overshoot, but are mainly useful for heating applications. You CAN use a PID in a cooling circuit, but the PID must be designed to not result in short cycling. PID's general nature is to have pretty short cycles, and in my opinion are not suitable for refrigeration applications for small units like a kegerator. A small overshoot will not affect a large thermal mass like a keg, so the PID function is irrelevant to this application.
Where a PID comes in handy is in heating circuits, like bbq smokers, where overshoot can affect the quality of your bbq. Overshoot is caused by the delay between the heat being produced, to the heat being detected. Undershoot is also a problem in some systems, so a PID is designed to slow heating as you approach the set point, to prevent going over. they are used in chemical plants on reactor vessels to prevent a chemical process from overheating and destroying the batch being produced... but there are many other applications for PID's. The PID output is typically a pulse width modulation, which works great for heating elements. But unless you force the PID to only use off-pulse widths longer than the minimum compressor hold-off time, it can't be used on a compressor. A typical PID will have the shortest pulse widths around 1/2 second or so, far too short for a compressor. Most chilling systems use a simple on or off thermostat, with an integrated hold-off feature, or the hold-off is incorporated in a time-delay relay or a controller board on the unit controlling the compressor. I've never heard of a system using a PID for chilling, but of course it is possible. I have seen systems that simulate a PID behavior, by reducing the compressor speed or compression ratio, like the new "digital inverter" compressors on some modern systems, but those compressors never turn off, they only turn down... And while they are controlled by something like a PID, it is not a PID, it is something else.
Bottom line, I don't recommend a PID for most chilling applications.
To determine what is a "short" cycle for your unit, get a stethoscope, and listen to the sounds in the cooling coils after the compressor is turned off. The best way to do this is to unplug the unit for at least an hour, so that is warms up several degrees. Then plug it back in, and watch it cool down. Before it reaches the set-point, and the compressor is still running, unplug the unit and note the time. While it is freshly off, find the place where the stethoscope produces the loudest sounds of the refrigeration gasses equalizing. Once you find that spot, listen as the sound diminishes, and when you can't hear it at all, note the time again. The begining and ent times are your "measured" equalization time. Now the actual equalization time is actually longer than your calculated time, and depending on how confident you had a good location to hear the gasses moving, you should calculate a time value to use. I would recommend at least 2 to 4 times the measured time, so if you heard the gasses hissing for 5 minutes, I would us a 10 to 20 minute timer value for the hold-off timer.
In your thermostat routine, you should timestamp the time you turn the timer off, and the routine that turns the compressor on should check to see that the hold-off time has passed, and delay startup if it hasn't. Also, if the unit is turning on after being off, such that the time off is unknown, the compressor should not be turned on until the hold-off time has passed.
The hold-off time is critical, otherwise you /will/ damage the compressor eventually.
The problem is that the compressor has a hard time starting up when there is already pressure built up in the system. Hard starts are very bad for the compressor. Most compressors won't start at all under pressure, but some will eventually start, but not without overheating. Heat will shorten the life, and even destroy the compressor.
I'm an engineer, I have a refrigeration license, I've designed PID's, temperature controls of various types, I ran an ISP for 20 years, and have designed control systems for a variety of applications, such as diesel engine computers , power plant systems and data center air conditioners. My passion is IOT, or at least networked control systems, so I love peeking into what other people are doing.
I use Zabbix for a lot of management purposes, and it has a discovery mode that you can customize. I used discovery in a large ISP environment to scan for new customer nodes coming online, scan the nodes for correct configuration, send alerts to techs when incorrectly configured systems or rogues were found, etc... The quality of the ISP's network went way up when we started detecting configuration issues BEFORE they caused problems.
The only downside is this is a rather application-specific service, so you have a challenge to make it application neutral. that probably means covering the basic common system settings, and making a API that is easy to integrate into the user's application. Being that these devices are great for swarm applications, your idea has a lot of merit. What would be better than a self-configuring swarm?
But I ageree this should be a generic Linux app, just keep it light weight so it works as well on small systems as large ones.
There are a lot of tools to look at that solve needs like this out there, in configuration management and system monitoring, so get some exposure to what others have done, might give you some good ideas.
I don't have my Onion yet, but I'm fond of using the login screen to display relevant documentation for the machine. I'm admin for a lot of machines, and sometimes when I'm trying to fix a machine I haven't logged into for a long time, I can't remember key files or settings, so I use the login screen to display useful operational hints, as well as status messages, notes, helpful hints, etc. So when I log into that server that just crashed, all my notes are there for reminders of whatever I need to know. It is also handy to put status like system state, free memory, free disk space, and any other useful diagnostic data I can figure out how to display. I usually have this info and more in a documentation wiki, or systyem monitor, but when the network is in a bad state, having the documentation cheat-sheets in /etc/motd or some other "in-your-face" location is useful.