On Thursday, 22 June 2017 13:23:35 BST Ralph Corderoy wrote: > I'm assuming that minimising power consumption won't be an issue either > way.
Obviously we won't want to install a heavier sub-station for the WMT, but no; we have no known issues with power ATM :-) > I'm guessing slave Pis will only be in the dozens, and readings and > all-hands-to-the-pump commands in the order of 1 Hz or slower? Essentially correct, although the initial installation won't include dozens of slaves (apart from the volunteers :-) ). > That's sounding as if you'd have a database server sitting on the > network with all the slave and the master being its clients, sending SQL > to modify tables. And if the slaves are writing to the tables, and the > master is trailing behind, reading them, then you're (mis-)using the > database as message queues. Perhaps a message queue would be a better > fit. OK. I've vaguely heard of message queues. > As Tim said, it sounds like overkill, and adds another major piece to > understand, configure, monitoring, debug, ... A message queue, like > RabbitMQ, or zero.mq, also has those problems given your simple needs. I'll look into those. > You're sticking with Python? And you've been dabbling with > http://flask.pocoo.org/, the web micro-framework? I'd try and stick > with those. Python has been adopted as the preferred language for WMT software by consensus. (Despite the fact that I had to fall back on C for the lighting software due to lack of Library support for hardware PWM in piCore.) I haven't done much with the flask stuff yet, due to 'one damn thing after another' on the home front. The web updater for the Audio Guide / Quiz was always a 'Desirable' rather than 'Essential' feature, so I'm focusing on fixing the blocked drain, broken tumble drier, central heating always on issues at home and trying to keep up with the River System development during odd bits of spare time. > How about having the master poll the slaves regularly, with a timeout. > That way it learns of slaves not responding. The slaves present a web > server that sends back the last-obtained readings when asked; GET > /readings. The same web server can provide a path for writing by the > master; POST /pump-speed. In the slave, you'd have flask manage > calling your bits of code to format the variables holding the readings > into the text reply, and parsing the new speed out of the text request. > Something like the APScheduler you're already familiar with can > regularly call your routine that reads the Pi's I/O. To safely stash > those readings from variables local to the function to those shared with > the web-serving side, look at > https://docs.python.org/2.7/library/threading.html#lock-objects to > provide the https://en.wikipedia.org/wiki/Critical_section Tim > mentioned. Thanks. I'll look into that. We want a webserver in the system anyway to provide a control panel for the WMT staff and an information panel for the visitors. Maybe I'll understand enough about flask by the time we've finished to get the web updater done :-) > (IIRC storing a value in a Python global doesn't need a lock, so you > could have a global holding all of the readings, and switch them > wholesale for a new lot with a single atomic STORE_GLOBAL opcode, but > it's simpler to tell you to use a lock. :-) I'm sure that when I've read up on all this, I might understand what you're telling me ;-( (It's the documentation that I have a problem with and that's mainly due to my lack of knowledge of the terminology used in the CS world.) -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-07-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
