Locking

[joelhaasnoot]

From what I can see bad things may happen if a request is fired with duration n and a second request is issued before the request is done. Not so bad for a grinder (if you like your beans the size of atoms), but for a heater this could have serious safety considerations, unless there's also a hardware failsafe.

[margyle]

So the way I have been handling this in the prototype is by having a separate script that actually controls the boiler. It accepts a temperature but not a timing variable.

For the API, there will be a pin lockout check on the relayController function. So in pseudo code, something like this: If (pin = heater){ return error } else{ GPIO.output(int(pinNumber), GPIO.HIGH } The pin lockout config would be in a text file, so for someone to override it they would have to manually edit it.

Then on top of that there is a safety override script that runs all the time. It checks current temp, relay statuses, etc. If any of them are out of range it shuts them down. Finally, there is a thermal fuse to kill the boiler if it it gets to that point.

And from my understanding, subsequent requests to a flask endpoint would not impact any currently running requests. I'd be interested in hearing if that is not the case as my initial testing seems to go along with that assumption.

[jjok]

@margyle Do you think some kind of per-pin locking would be useful? I guess that's what @joelhaasnoot was thinking.

You could do something like:

if(fileExists("pin17.lock")) {
    return or throw Exception
}

createFile("pin17.lock")

doSomethingWithPin17()

deleteFile("pin17.lock")

[levi]

Would be great to write a little daemon process that constantly reads the status data of each device connected to GPIO and stores it in memory. The REST API would then simply send commands to this daemon and lock various pins based on statuses provided by the device. This would allow for new protocols like MQTT to be added to Mugsy, allowing for realtime pub/sub that REST doesn't provide.

@margyle, is there any way to read the status that your safety override script uses from the GPIO pins of the raspberry pi?