A couple of field requests to improve groov events.
[1]. Add color control for the alarm indicator to show at least one of the events is active. A blue color would match the indicator bullets, but pushing the boat out, it would be nice to have a single color configuration for the general indicator bell alarm and configurable colors for each individual events as it appears on the detailed status list. Just saying.
Example1: No configured and enabled event is active:
Example2: At least one configured and enabled alarm is active
[2] Add the ability to allow an operator to switch the ENABLE/DISABLE for specific events from within a page through a widget. At present the only way of blocking a nuisance event with a faulty input sending multiple SMSs and emails is to access groov build from a PC using an editor account, change the attribute to DISABLE, resave the project and reload it on every end device. Messy.
[3] Accessing events on a PC allows you to sort events by Event Name, Active/Inactive and Enabled/Disabled. These options are strangely missing on the movil app. (At least on IOS).
I.e. While any active event makes my alarm bell turn red to notify me, its more important to know that my freezer door is open than knowing my fuel level is high advisory.
[1]. Add color control for the alarm indicator to show at least one of the events is active. A blue color would match the indicator bullets, but pushing the boat out, it would be nice to have a single color configuration for the general indicator bell alarm and configurable colors for each individual events as it appears on the detailed status list. Just saying.
That’s definitely on the next release list. I’ve been thinking both a color + the number of active events:
Although it starts getting a little crowded on mobile.
[2] Add the ability to allow an operator to switch the ENABLE/DISABLE for specific events from within a page through a widget. At present the only way of blocking a nuisance event with a faulty input sending multiple SMSs and emails is to access groov build from a PC using an editor account, change the attribute to DISABLE, resave the project and reload it on every end device. Messy.
You shouldn’t need to save the project or refresh any browsers: just toggling that Enabled/Disabled switch should do the trick. (Did you mean something else by “reload it on every end device”?)
It’s a little hard to make out here, but toggling an event Active/Disabled should show up on your device within a couple seconds:
I agree that you shouldn’t need to get into Build to do something about a broken event. There’s no reason you shouldn’t be able to turn it off in the middle of the night from your phone.
[3] Accessing events on a PC allows you to sort events by Event Name, Active/Inactive and Enabled/Disabled. These options are strangely missing on the movil app. (At least on IOS).
I have the sorting options on the mobile app here, but the dropdown is named “Status” instead of “Sort By”:
So will we have an configurable option to permit enable/disable events at a Operator Level? It would be nice to have this configurable as part of the individual event.
Yes. It threw me to find them labelled different. I guess different people worked on the mobile app. 
While on the subject of access, perhaps it isn’t such a good idea to let an user with Operator Level default access to delete the log. I presume he is doing this at the groov level and not at the end device level?
Although it starts getting a little crowded on mobile.
Really nice feature to show the number of active events next to the animated alarm bell symbol. Looking forward to seeing it. If its getting cluttered, I am thinking we could drop the word “Events” between the alarm bell symbol and the number box. The bell icon is good enough to explain itself.
While on the subject of events, how about relating event audience to certain users, using either groups or specific groov users. This will allow a user to only have visible the event notifications that really concern him. I.e. operator vs supervisor. Internal staff verses external maintenance contracts. Different plant areas. etc etc. I am sure you understand the idea.
Yes. It threw me to find them labelled different. I guess different people worked on the mobile app.
Nah, just an oversight. To be clear: the groov mobile app is simply a web browser wrapped in a UI that gets rid of the normal browser stuff, like the URL bar. It’s meant to enable running groov as a kiosk. You’ll get the same web application if you just visit your groov instance in your normal web browser on your phone. On iOS at least, it’ll generally be faster in Safari than in the groov mobile app: the mobile app can’t currently take advantage of Safari’s JIT.
While on the subject of access, perhaps it isn’t such a good idea to let an user with Operator Level default access to delete the log. I presume he is doing this at the groov level and not at the end device level?
Right, the event activation log’s stored in groov, not on the devices.
If its getting cluttered, I am thinking we could drop the word “Events” between the alarm bell symbol and the number box.
Yeah, I’m already dropping “Events” and “Menu” on mobile. It collapses down to look like this:
So do we agree that its not so good to allow any operator user delete the entire groov event message log, which could contain some pretty revealing information in case of an incident?
I remember many years ago we had a fire at one of our customers sites, a pulp and paper factory. Turned out the damage was limited to a line printer and its paper printout that continuously logged all operator actions during the night shift. The official investigation and final report stated the cause as either “an electrical fault” or “spontaneous combustion” 
Operators can’t clear the message log. The button’s there (another oversight), but it doesn’t do anything.
Just loaded the latest greatest groov 3.5a and see that we now have active event totals. Well done. I see that configuring the event indicator colour for the coloured ball indicator did not make the cut though. 
Is it still on the “to-do” list or is it firmly on the “not going to do” list? Its purpose was to indicate which events are more important than others. Remember?
Reviving the subject a little another idea was to assign events to user groups. Not everyone in a factory is interested in all the configured events for all areas.
I see that configuring the event indicator colour for the coloured ball indicator did not make the cut though. 
Is it still on the “to-do” list or is it firmly on the “not going to do” list? Its purpose was to indicate which events are more important than others. Remember?
Not off the table, and something we have in mind, just haven’t gotten to it yet. This release was largely focused on stability and scalability, and the View mode shell was refactored to make it easier to support new features in the future. Clearing up technical debt and whatnot.
