I think it's more likely that the tablet has some knowledge of who has an appointment that day. possibly that hour. and can keep asking questions till there is only one possible answer.
I have never seen a list of names, nor have I ever had to press "No".
I suspect that if I did press "No" it would say "You do not have an appointment. If you have a medical emergency please go home and dial 999"
I certainly hope so. Though knowing some of the GP system vendors, nothing would surprise me any more.
or maybe "Please book an appointment using the NHS App"
Give each member a keyring RFID tag.
Edit: adjusted for hot climates.
I would have a very very low tolerance of some sodding machine bleeping and flashing lights at me if I wave my keys at it wrongly. Especially if there's a pint of warm ale cold lager waiting with my name on it.
4 Likes
Thanks all.
Another BIG ISSUE I now have!
For the sake of it, let's say we need only the person's name.
First and Last as there are a lot of people with the same first name.
Big problem for me if I am going to Offer this as an option.
Why?
Well, let's say we have a data base with the people's names.
Fred Flintstone
Barney Rubble
Wilma Flinstone
Betty Rubble
Bambam Rubble
Pebbles Flintstone
(No, I have no imagination)
All the names would be stored in a database!
The names appear as buttons on the screen, as adding text to buttons is easy.
I just said buttons in two ways. That's because I'm not sure that will work.
See below.
Though I fear it won't be that easy.
Let's say we have a long list of people attending.
They will appear as a list of buttons that scrolls once the screen is full.
They would be sorted in alphabetical order. Not the order in which they arrived.
So a BIG PROBLEM I see is how to sort the list of names each time a new one is added.
And another BIG PROBLEM is how to update the names available when new members are added?
To Log out they press their name on the list.
Though I am not sure if that should be DOUBLE press.
To get around accidental pressing when scrolling.
(Not sure yet)
Summary of new Problems
- Create a list of names from a dynamic database for when people log in.
- Sort the list of people alphabetically on the screen when new people come in and others leave.
New thought - just talking here.
When people leave for that day, rather than deleting their name:
Mark them as departed.
This way if you want to know if someone was here and you can't find them, you can look in the list and see they have departed. (Or not so you know to keep looking for them)
For people signing in/out:
Depending on how long that list is, you may need to split it - maybe 2 levels, first name level and then filtered to first name/last name. Not a problem though if the possible list is manageable (which it probably won't be if it goes over >1 screen).
Or use an on-screen keyboard and dynamically filter as people start to enter their name. This is how most UI's would do it.
So you have a master reference list of members? People register their presence so they are copied to the "live" data and when they leave, they are removed from the live db.
The live data can simply live in the browser if you only need a single device. Just some JSON should be fine. Send in/out notifications to Node-RED so that you can keep records for management information.
If your live data is an in-memory array (JSON), then sorting is a single line of JS.
The tricky part is dynamically changing the UI. And that depends on what "helper" library you will be using. Will you be using D1, D2 or UIBUILDER?
Ok, I made a mess of the explanation.
The database is the full list of members. (Not changed daily) It is from where the list of available names is ..... sourced.
For the sake of simplifying it, I'll say the search is done for their first name.
So when they go to sign in - from my example - Fred will press the F key.
All the members names (first) starting with F will be listed - alphabetically.
They see Fred Flintstone. Press that button, and they are then signed in.
I'll stop that part here.
Sorting: Great.
WRT which dashboard..... I - on my machines - am on the original one.
I have no experience with either of the others.
I'd guess D2 may be better/easier?
Clearer?
Ok, to help with the example, I'll give a better list of names:
Andrew Black
Andrew Jones
Chris Jones
Chris Smith
Garry Patterson
Greg Lenton
Harry Hudini
Larry Lounglizzard
Peter Jackson
Xavier Alba
(Yeah, I need to get better at making names. But this is at least a bit better than the original one I posted.)
So if Andrew comes in, when he presses A he will see the two Andrews listed and press his one.
Assuming that the members list isn't millions of people 
, I would dump a copy of it to the browser every morning or on page reload. I have a page that gets a list of at least 18,000 people entries - I load it from a CSV as it happens (using Node-RED of course) - on page load, it is read and sent to the browser. Once in the browser, it takes around 1.4 seconds to turn it into the live data (it gets restructured from a flat form to a multi-layer object which is a pretty heavy process) and then it builds the full list in the UI. So that's a LOT of front-end processing! Yours should be much easier AND you won't need to worry about UI load performance since you can simply do it automatically each morning.
Weeeeeeellll - would you really expect me to say that! I personally think you would be better off using UIBUILDER to create your bespoke web UI without the need for all of the Dashboard overheads. BUT, I recognise that would require some learning on your part. BUT, you will certainly be having to do that anyway in switching from D1 to D2 so why not use UIBUILDER where you will mostly be learning how to use modern HTML rather than being restricted to a single framework. 
But the choice is yours. Either UIBUILDER or D2. D1 is end of life.
Yup, I get it. All very straight forward. BUT, not, I think, standard D2 stuff so in any case, you would be creating custom stuff. In my personal view this is easier to do in UIBUILDER than with D2 who's main aim is to make simple dashboards trivial. UIBUILDER's main aim is to help build data-driven custom UI's.
1 Like
Yeah, I kinda forgot that the entire list needs to be.....
Well, hang on.
I really have no idea on the mechanics of how this bit works.
NEW DAY Things are reset.
The member list is - round figure - 150 people.
That's a data base and is loaded into NR.
There is a RUB for me there, but I'll get back to that later. It isn't critical, but is problematic at this point as I see things.
A list is held by the program.
Person 1 comes in and taps the log in button.
26 buttons appear - and some others, but for the sake of keeping to the task at hand......
They press the letter for the first one of their first name.
All members with the first name starting with that letter are displayed.
(Things get complicated here)
There wouldn't be more than 10 people with the same first name.
In this case TEN buttons are displayed with all the names. First / Last.
They tap that button and they are marked as in.
The screen wipes and then displays a list of in members and they are the only one shown.
Second person comes in.
Repeat of most of what I already said.
They click their name.
The screen is wiped and the list is recreated and displayed. (Sorted)
All names are buttons so the people marked as in can click again and become out.
When they click their name again, they are marked as out. Their name stays on the list.
This is wiped/reset at mid-night.
Stuff could be done with names still marked as in at the end of each day.
I shall concede (admit?) that UI_Builder may be the way to go.
But that is ontop of the dashboard - or a complete replacement of?
Sorry, again: I've been happy with the toys I have and this is something which has got my interest.
Other stuff would be logged also - but hidden from the user - like time/date of in and out.
Maybe show the out time to help people looking for someone who's gone home.
Did they just leave, or did they go a while back?
Alas I'm probably going to have to make a test run of it and I don't have any machine with a either dashboard 2.0 or ui builder free.
That's going to be fun for me working that problem out.
Sorry, my problem.
Shall have to see if I can dig up an older machine - NUC - and get it up to date with ui-builder.
But it would only have a VERY EARLY version of NR on it.
Like 1.x or maybe even earlier. 0.9?
Are the functions I mentioned within the scope of ui-builder?
- Getting a list and making each line it's own button
- Allowing change of text displayed in said button
(Refreshing of screen is ok.)
There are other things needed, like who is in charge that day button.
And maybe a menu for admin stuff.
Oh, back to the problem I mentioned way back:
The main list would be stored on an external machine.
That way admin can add/remove members and this propagates to this machine.
So it would/could be a network mount and a watch for if/when the file is edited.
Is that possible?
And - alas - it would be probably not much more complicated than a CSV file. 
JOSN is asking too much of the powers that be.
Though it would probably have a lot more information than just names.
But that could be filtered out (parsed?) when the file is read. Yes?
Logging would be needed too.
Unsure of the specifics. But things like daily numbers attending. Names maybe needed.
I'll stop here.
Thanks.
Well, as this is effectively a stand-alone system, the only impediment to using a different "toy" is the learning aspect. And that probably comes down to any desire (or lack thereof) to learn something new and whether you think that learning VueJS as a single, specific framework or UIBUILDER as an entry to learning W3C standards-based web app building is more useful to you.
Either tool is a valid approach. But I don't believe even D2 will give you a lot of help and so you are likely to still need a fair bit of bespoke code. Personally I find UIBUILDER easier to do at least simple bespoke stuff than I do VueJS. Because you don't really need the help that VueJS gives. Frameworks like Vue are good for really complex web apps or maybe where you have a team of people working on a web app.
But to directly answer your question - UIBUILDER can and does work ALONGSIDE both D1 and D2. Having an integrated page using a mixture is bit more complex but in this case, your new page is a stand-alone page anyway.
That is not a problem. UIBUILDER can be installed and won't impact ANYTHING. It adds some overhead of course but not a lot. You can, indeed have UIBUILDER, D1 and D2 all installed on a single instance of Node-RED with no problems.
OK, so don't forget to keep the Node-RED and the browser parts separate in your head. D1/D2/UIBUILDER all deliver data to the browser where processing happens separately from what happens in Node-RED which is on the server.
If you follow a UIBUILDER path, you are able to create a web app that can be (if you want) COMPLETELY separated from any other web app (e.g. one for management information).
So you will likely add a uibuilder node to your Node-RED flows that will deliver the page for the members. You dump the master data to it and let the browser do the processing. But you add a simple function to your buttons so that user in/out button presses are send back to Node-RED for other processing. UIBUILDER's client library has simple functions for doing that.
YOU then have the choice as to whether you put your management information processing onto the same UI as your in/out OR put it onto different page(s), using another uibuilder node. You have all the relevant data in Node-RED (on the server) and so can process it wherever you want, send it and/or store it as desired.
Or simply run up another instance of Node-RED! If you really want to keep this separate.
You certainly don't want that. You need current versions of everything.
Absolutely. Or, more accurately, they are in the scope of HTML, CSS and Javascript and may be helped/made simpler with uibuilder
In fact, UIBUILDER will give you several options for doing this. UIBUILDER's no-code nodes have both a list element (just send it an array) and a way to easily update any on-page element such as a button. For the updates, all you need to do is to make sure that every button has an id attribute that uniquely identifies it.
So you could run all the processing from Node-RED and might not even need any front-end code. Though that would increase the dependency of networking between the tablet and the server (assuming they are separate devices). Given the preference for tablets to going into a low-power mode and cutting off comms, my own approach would be to minimise that and simply minimise the comms doing more processing in the front-end. But the point is that UIBUILDER gives you the flexibility to do it the way you want. I'd be happy to work through some of the options with you as you home in on a preferred solution.
Which again could be part of the same page or on a different page via a different uibuilder node if you want. With the advantage being that different people could connect to the management page(s) and would not need to be bothered with the in/out page.
Absolutely. On the understanding that you are running Node-RED on a network that has access to the data. Node-RED manages the DATA, UIBUILDER manages the communication between Node-RED and the browser.
The data can be file-based or a DB or some mix. Node-RED provides the interconnectivity.
Absolutely no problem. As mentioned, I already use Node-RED and UIBUILDER to process big CSV files from work such as a dump of our 18,000 staff details. Seriously, this is pretty trivial. And I can help you with some recommended 3rd-party libraries for processing tabular CSV data should you want to do the filtering and/or reshaping of the data either in Node-RED or in the browser.
Yup, Node-RED will take care of that as well.
You will have the data in Node-RED if you follow the process I outlined before. So processing, storage, logging not a problem. And display of that management information simple enough, either to a different page (could even be a D2 dashboard!) or to the same page but hidden from normal view behind a menu, all straight-forward enough.
1 Like
I think that you should consider taking a step back and look at Australia's privacy laws around storing & processing personal data first, and then build your framework around it.
For example;
In the UK, you would not be able to do this, because you would be exposing personal information (First/Last names) of members, to others.
It's a long since I had anything to do with GDPR, so there may be exceptions, or workarounds, but it's worth exploring legal options before spending too much time on system design.
3 Likes
Whilst checking the law is always a good idea. In most cases, you would indeed be able to do this since not only should members have signed up and therefore agreed to some level of data sharing, just the names are not considered privileged information in the context of a signing in/out "book" which is, after all, not exposed to the Internet.
However, you absolutely should ensure that the terms and conditions of membership include some minor level of record keeping.
I'm not an expert on Oz law but to the best of my knowledge, their privacy laws are not that different to ours. I'm not an expert on UK law either, but I do know a fair bit about UK privacy, Information Governance and the use of sensitive data.
So assuming this is a "private" club in that it requires members to sign up, you are likely well covered already. If in doubt, also put up a sign for a few weeks before implementation telling people what is proposed and giving people a way to object if needed.
Andrew has not mentioned it being a 'private' club with no unauthorized access, so we really don't know much about it's status, and that's why I suggested doing the research first to find out what exceptions/workarounds there are in Oz law, before spending time on system design.
This is a quick guide for UK small clubs/societies, which raises a few things to consider, but Oz compliance may be different.
Well, there is (now) a big board with all the member's names (first/last) and we all wear our name tag when attending.
So seeing other names when signing in isn't really a problem for privacy, as all the names are visible anyway.
But, point taken.
1 Like
@TotallyInformation
Thanks very much for that reply.
I'll dig up the other NUC I hope soon and get to updating/installing the stuff this afternoon.
So if I run another version of NR - keeping the status quo on the machine - all I'd do is make a new .node-red directory (say .new_node-red) in the home directory and run the install script from there - yes?
You can call it what you want, you provide the folder as a parameter to the startup.
If you want to run the same version of Node-RED, that's all you need. If you want to use a different version of Node-RED, you can use my alternate installer or install manually to a new folder.
Oops,
If you say I can run ..... ui-builder on top of the dashboard then there isn't a problem.
I'm about to start the journey down this now.
Hi Andrew,
I have Dashboard 1.0, Dashboard 2.0 and UIBUILDER all running in the same installations of Node-RED 3.1.9 both on an RPI4 and an Ubuntu 22.04 Laptop.
I have had no conflicts with any of the flows/web pages I run in parallel.
2 Likes
Thanks.
I'm in the process of updating an old NUC from 18.04 to 24.04. At the last stage now. But it is slow going.
Would it be ok to ask you for help with the concept of how to do things with uibuilder?
Just that as much as other people have helped to now, I don't want to abuse their help.
That's meant in a kind way.
As I have 0% understanding of how to use uibuilder and I believe it may be a bit of a challenge.
Only based on most things I take on are way above me. 
