Webserver Development

[hamishmb]

Okay sounds good.

Note that'll you'll need extra socket on both pis to talk to the webserver, and two separate sockets for the webserver, one for each pi

[TerryJC]

Okay sounds good.Note that'll you'll need extra socket on both pis to talk to the webserver, and two separate sockets for the webserver, one for each pi

I had realised that the Webserver would need another socket, but hadn't quite appreciated that there would have to be extra sockets for the other ends.

It's obvious when it's pointed out.

[TerryJC]

Okay then, if IPC is complicated/difficult to do I agree it probably isn't worth doing. Using the sockets code is probably fine. Hopefully you can also use sockettools.py (it may have to be installed under /usr/lib/python3.x/site-packages/ for Flask to pick it up, depending on how imports from Flask work).

One of the people on the Raspberry Pi Forum recommended this earlier: https://rpyc.readthedocs.io/en/latest/. It seems to be a bit simpler than the other stuff I've found.

I don't think I will use it, but it may be useful.

[TerryJC]

Okay sounds good.

Note that'll you'll need extra socket on both pis to talk to the webserver, and two separate sockets for the webserver, one for each pi

Hamish,

I have new versions of the Music and Bells programs running which successfully use sockets code to signal the start of the Wedding Changes and will eventually be used to move copies of a List containing the status of all the monitored functions.

I have the sockets code being polled for new data every second and found that this increases the CPU Load by four or five times, but it's still only about 10% so I'm not going to worry about that. (That's on the Pi Zero by the way.)

I've been think about what you said and believe that a slightly simpler approach would work for my requirements. In essence this would be:

• The Bells Pi, which is the Zero, will do nothing except listen for commands over the sockets code and respond accordingly. At present the only command fully implemented is the one to trigger the Wedding changes.
• The Music Pi will ask the Bells Pi for status data, when it's needed, which is every time the Webserver asks for an update.
• The Music Pi will therefore maintain the list of status values for both Pis and pass it to the Webserver on request.

If this proves a successful strategy then the Webserver will need one socket, the Bells Pi one socket and the Music Pi two sockets. What do you think?

Assuming that the above strategy makes sense, would you agree that the Webserver should be a server so the Music Pi has one server socket, to talk to the Bells Pi and one client socket, to respond to the Webserver?

[hamishmb]

Glad to hear it's working well

Yep, sounds good to me. It doesn't really matter which one is the server, but I agree that it makes most sense the way you've described.

[TerryJC]

I now have a prototype Webserver which provides status and control of the functions in the Music and Bells Players; see the screenshots below:

Minster_Status.png (198.19 KiB) Viewed 708 times

Minster_Control.png (186.03 KiB) Viewed 708 times

In the tables on the Status Page and under the control buttons the values will eventually be the ones you would expect. The strings shown are simply place holders for the actual data that will be displayed.

Penri,

Do you have any comments on this layout or the content?

My next job is to integrate the web code with the Players code so that the correct data is made available to the web pages.

[hamishmb]

Well done, this looks really nice

[TerryJC]

Sitrep:

I believe that the basic Webserver code is now working pretty well. On the Status Page it displays the contents of a List called Status[] that contains the data required (just the placeholders at present as shown above). On the Control Page it generates a proper response in Python when a button is pressed (just a print statement at the moment). I have also added a button on the Control Page so that navigation between the two pages requires only a button press.

All that remains now is to add the sockets code to populate the List with data and to send a message to the running programs on each Pi to carry out the required functions and update Status[] accordingly. That will be done over the next few days I hope.

I have pushed this version to GitLab at https://gitlab.com/wmtprojectsteam/mins ... ngineering if anyone wants to have a look.

All comments are welcome.

[TerryJC]

I've just realised that the Webserver code does not in fact include all of the functions that will be required. Yes. It allows monitoring and control of all the functions in the Requirement, but it does not have any authentication code.

Now I think that this is really bad Unlike the various Pis in the River System and elsewhere, this Webserver is not protected by the normal linux login process. The two Pis themselves are if someone accesses them over SSH, but the Web Pages provided by this server are not. This means that anyone who connected to the WMT WiFI and then found their way out of the main Webserver pages (which have no sensitive interfaces) could use the Control Page to do stuff to the Bells and Music settings that the Staff would certainly not be too happy about.

I feel therefore that I need to implement a login page on this server and ensure that at least the Control Page is protected. I'm assuming that no-one disagrees with this.

However, what about the Status Page? In itself it only provides information and cannot be used to modify the running code, but it may be better to protect the whole thing. Any thoughts on this? If the Status page was unprotected I would label the "Switch to Control Page" button with a message "Staff Only" and the login page would then pop up when someone pressed the button.

[Penri]

Terry

The interface pages look nice and should work well.

On the log in issue if it's not too much extra work or a security compromise I'd prefer the status page unprotected and with the controls behind a log in.
That would allow the WMT volunteers to monitor but not change settings.

Thanks for the e-mail alerting me to the post.


Penri