User Interface

[hufftheweevil]

As mentioned in another issue, I'm interested in building a (simple but robust) UI so that we can manage our nodes from within the Node-RED editor. I'm going to begin development on this and hopefully have a demo out within a week (we'll see). My goal is to make something that is as minimal as possible but allows us to do just about everything we need to do with the nodes.

Main ideas/features:

• The UI will be in the sidebar, as an additional tab
• The main part will be a list of all known nodes with basic ID info and statuses
• Click on a node to get into it's details (version info, configuration, and all other values)
• While in the node, there will be some interaction to allow configuration changes
• Additionally, will be able to set other values (depending on CC)
• Back on the main "page", options to start/stop inclusion, get nodes, and do other controller functions
• The Node-RED comms API will be used to communicate between the runtime and the browser client
• Decision to be made if the client will keep its own cache of data (and update it based on events), or if data will be requested from runtime only when necessary (i.e. when user shows the tab, clicks on a node, etc). Second method is more simple, but first method offers more flexibility in the UI

If you have suggestions, ideas, comments, please post them here.

[marcus-j-davies]

@hufftheweevil

Back on the main "page", options to start/stop inclusion, get nodes, and do other controller functions

The current method of controller management (Using the class 'Controller'), I don't like, so your suggestion here, is a much welcomed one (as with all your points).

but maybe test you can push? https://github.com/zwave-js/node-red-contrib-zwave-js/issues/20#issuecomment-773541248 Do you think this should be a 2.0 release?

[hufftheweevil]

Sorry, it's been a busy weekend. I have confirmed I can push directly to dev branch.

Yes, I think it would warrant a v2.0

[marcus-j-davies]

Can you see much more being done for 1.4? the list todate,

• Bump Z-Wave JS to 6.1.3
• The response to the Unmanaged method GetValue is now delivered via a GET_VALUE_RESPONSE event, where the object property contains the return value, and the Value ID
• Fix Node Red crash on failure listing serial ports (#18)
• Optimisations to speed up initialisation of already inetrviewed nodes (#20)
• Added Thermostat Operating State CC
• Added Thermostat Setback CC
• Added Color Switch CC

I will want to create a 2.0 branch, so hoping that nothing more will happen after 1.4

What are your thoughts on Managed vs Unmanaged? personally, I don't like using the ValueID methods (unmanaged) - it requires a constant list to be available to call commands, and for new users in home automation, it is a little daunting, having to keep/fetch a list of ValuesID; as apposed to the Managed approach where the command is almost self explanatory .

Managed Pros - Easy, self explanatory, device polling Managed Cons - We have to bridge the CC's via the functionmaps json file

Unmanaged Pros - CC support is only limited by z-wavejs Unmanaged Cons - More mileage needed for the end user, no device polling

We will keep both of course - but anything on how to make this more streamlined?

[hufftheweevil]

I think that's a good list for 1.4.

What is the purpose of the FunctionMaps.json when pretty much all of the "operations" map to a function of the same name, just using different case? Same with the CCs getting mapped...the only difference is spaces. I feel like it could be simplified to work exactly as zwave-js works, eliminating the need for a bridge. On that note, I think the same could be said about the events as well.

On the other hand - we are trying to make zwave more user-friendly, and so I get the idea behind whole Managed thing. It is incredibly useful to have defined param types for certain operations. So I'm not advocating for getting rid of it or anything. In fact - I think we should make the Configuration/Set operation even easier by allowing a decimal params as an option. Most people aren't used to working with hexadecimal.

I wonder if we can kind of combine the two methodologies. Let the user specify any CC in zwave, and any operation for that class. And we just call that method (if it exists), along with the params. The user can choose to use raw param values, or a more friendly version (based on the type enums). Docs can still specify the CCs that offer friendly input.

Anyways - that's by 2 cents,

[marcus-j-davies]

During early development.

I had a case statement for all the CC's, and each case called the CC as it is, this resulted in all the calls to zwave js being written as functions in the js file, plus having to do all the param checking for each function, and what not.

Previously it was like.

case "Configuration":
     Driver.Node.get(3).Configuration.set/get

case "Basic":
     Driver.Node.get(3).Basic.set/get

Repeated for every type of CC/operation

Later, I learnt the CC's can be accessed via its key, so decided to create the bridge - this allowed a universal piece of code to execute any of the CC's, whilst checking for the required no. of params and removing a lot of unnecessary code.

There is also the issue of enum values for some of the CC's, function maps converts them to the required numericle value. otherwise the user will need to supply numerical data - having to review a lot of buried code in zwave-js.

function maps does all the checking that they have submitted everything correctly (for the most part). Some CC's are not async either Association being one, function maps takes care of this.

Function maps is a translator if you will, between the user and Zwave-js. if we can make this is Evan easier, whilst keeping the simple approach in tact - i'm all for it.

[hufftheweevil]

Just a quick update: UI is coming along well. It's taking a little longer than expected; work has been pretty busy.

A couple of non-UI features that I had to add to aid in the UI (and that might be beneficial for other purposes) were:

• An Unmanaged operation GetValueMetadata that does just that.
• A Controller operation SetNodeName that does just that.

More info and a demo to come soon!

[marcus-j-davies]

I will be dropping 1.4

Given your involvement - I will be increasing your rights also. 👍 Your new rights, should allow you to create a 2.0 Branch - let me know otherwise.

EDIT: Have logged a bug in zwjs (which is now fixed) - (#1781)

Battery operated nodes, will wait until the lowest battery operated Node ID gets interviewed, before they get interviewed. again - this has now been fixed, but I will wait until its released.

PS: My time has been working on this (WIP) : https://devices.zwave-js.io/

[hufftheweevil]

gui branch published! Not sure if you want to merge into dev branch and test there, or just test from the gui branch. I should have named it 2.0 or v2 but I had started it before we made that decision. Anyway, I've pretty much fully tested it with my controller. But let me know if you find any issues with it.

For now, it gives you a new sidebar tab that lists all of your nodes. Click on any node to load all of the properties (obtained via the GetValueID operation). For each ValueID it also requests the value and metadata. If the property is writable, a pencil icon will appear and clicking the icon will show options to change the value. Properties associated with an endpoint will have the endpoint number to the left of the property. Properties with multiple values (using property keys), are expandable. And for both the controller and selected node, there are extra options available (see Show Options buttons) for easy access to some useful operations. If you or anyone else has any suggestions, please feel free to request.

Edit: Oh, and the device browser is great! Much better than sifting through all those files. And I see a ConfigManager has been added to Z-Wave JS. That may come in useful for expanding the UI here to include more information about each node.

[hufftheweevil]

After playing around with it for a bit, I think there is definitely a need for some CC-specific UI. I designed it to be pretty CC-agnostic (although it favors the Configuration CC - since that was the main reason I developed it). But some CCs, like the Binary Switch and Meter CCs aren't super useful presented the way that they are. Later this week I'll work on some tweaks that will improve areas like those.

[marcus-j-davies]

Ok,

Having played with the UI a little, I gotta say, its pretty efin slick. For network/node management, the UI is where you should be - Full Stop!.

I now see this node as having 3 different view points.

Managed : For users new to home automation/want to get up and running quickly, Unmanaged : For experienced/hardened users of the zwave protocol and/or zwave-js. UI : For network / node management, and for testing nodes in real time.

The UI really does add another level of functionality which works for both experienced and unexperienced users - Great Work!. 👍.

I think the ReadMe should absolutely suggest this area of the node for zwave management,

I think we should make clear however, about what each angle of the node is trying to achieve. As an example - would the UI be suggested for actually turning on a light? - then again, I supposed its up to the user, but we should assume some use cases with each angle.

I will be doing some more testing soon, but off the bat, I have only 2 suggestions.

• Manufacturer Specific I think should display its values as hexadecimal with padding - 0x0086 z-wave js, uses this format for a lot of display purposes

• Keyed Properties (aka Partial Params) Should have its parent node titled something like Partial Parameter(s) (Bitmask) see https://devices.zwave-js.io/?jumpTo=0x0129:0x8008:0x0a00:1.78 - param 23

  I have renamed the branch to 2.0 - I think this should now become our development branch. and once 2.0 is ready for release, I will rename it to main and retire the current release branch.

  Once again @hufftheweevil Great Work!

[hufftheweevil]

Thanks for the support. And to be honest, it's not even my best work. I'm a die-hard React guy - so I excel in that area. But jQuery works well enough here.

I always imagined the UI was mostly for configuration and testing. Which is essentially what the Node-RED Editor is for, overall. So it seems only fitting. If someone is looking for a more polished UI to interact with their system, then I recommend they tie in a purpose-built UI node(s). Of course, to each their own when open-source.

• Manufacturer Specific CC Agreed. I will try to use the ConfigManager to also resolve the names and display everything (maybe with tooltips)

• Keyed Properties Yeah I was trying to think of what to do there. There is no metadata for the full param - when I use GetValueMetadata for one of those, the response is {type: "any", readable: true, writable: true}. So there is no label or description. However I'm just realizing that when retrieving the ValueID list, the results are a little odd compared to what I'd expect. See example:

  {
  "commandClassName": "Configuration",
  "commandClass": 112,
  "endpoint": 0,
  "property": 31,
  "propertyName":"LED 1 Blink Status",  // This is the name for the property (but in reality, it should be something like "LED Blink Statuses")
  "propertyKey": 1,
  "propertyKeyName": undefined  // If the ValueID has a propertyKey, then why doesn't it resolve to a name? I would assume it should be "LED 1 Blink Status"
  }
  {
  "commandClassName": "Configuration",
  "commandClass": 112,
  "endpoint": 0,
  "property": 31,
  "propertyName":"LED 2 Blink Status",  // If this ValueID is for property #31 as well, then as a user I would assume it would have the same name as above, but it does not
  "propertyKey": 2,
  "propertyKeyName": undefined  // Again, I would assume this should be defined as "LED 2 Blink Status"
  }

• Version CC Maybe automatically determine if a firmware update is available, and provide a button to easily do the update.

• Units Show units for those that are known

• Meter CC Properties value, previousValue, and deltaTime are difficult to read, especially if there are multiple endpoints. Could integrate some of them together in a general way.

[marcus-j-davies]

Agreed. I will try to use the ConfigManager to also resolve the names and display everything (maybe with tooltips)

As long as the primary display is to showing the hex values - a lot of discussions on the ZWJS repo will include ID's as apposed to names

Yeah I was trying to think of what to do there. There is no metadata for the full param

Yup - the full param, wont actually be stored as one whole parameter Any param that uses a bitmask, is actually stored as separate params, in the config (1 for each bit)

See the config file structure below (though this is on the radar to have some updates) .

23[0x01] 23[0x02]

This extends to your examples above. config Param # 31 - doesn't control 1 thing, it controls many different properties, based on the bit being set (property key) - in this case 2 different LED's

for this reason, each modifiable property (or more accurately setting) will have an entry. The ValueID interface is heavily used for UI's, and in most situations, the ValueID interface is 'unseen' by most users.

Another good example is here (a device I actually own). https://devices.zwave-js.io/?jumpTo=0x0175:0x0004:0x000a:0.0 Config param # 7 controls 2 entirely different settings. - hence, 2 param entries

Maybe automatically determine if a firmware update is available, and provide a button to easily do the update.

Not sure how we can implement that - might be overkill

EDIT: ZWJS does support the Firmware Metadata CC, but not sure how we can check for the latest firmware for various MFC's.

[hufftheweevil]

Just pushed some changes to the gui branch.

• Manufacturer Specific CC Hex values shown. Friendly names are shown in the header/options area. Also included a More Info button that displays node metadata.

• Keyed Properties Simplified properties to all be at the same level, regardless of property keys. As you kind-of put it, the user doesn't need to really worry about that.

• Version CC/Firmware Metadata CC Yeah - harder than I thought it would be. Will look at later.

• Units Added

• Meter CC No idea what to do here. Could come up with something pretty clever, I'm sure - but it probably wouldn't match with the rest of the property list. Will look at later.

• Endpoint filter Added

Edit: Also just added a button to jump to the node device in the Config DB Browser

[marcus-j-davies]

Edit: Also just added a button to jump to the node device in the Config DB Browser

Nice touch 👍

Meter CC

I haven't looked too much in too that CC as of yet, I will try and see what's possible this week. I'm gearing up to switch on device voting on the Browser

Getting over 'man-flu' presently

[marcus-j-davies]

just tested - real nice 👍

on the next push - I feel its only right for you to add yourself as a contributor to package.json so please feel free todo so. 👍

Edit: We should also bump the lib version - currently, ZWJS is at 6.5.1

[marcus-j-davies]

@hufftheweevil,

I'm going to start pushing some updates into the gui branch.

Have just pushed some.

• Bump deps
• Driver timeouts, now use Z-Wave JS Defaults if not provided (clearing them, means they will use the latest as suggested by z-wave js).
• Removed awake time config
• updated read me
• Added you as a contributor to the package file
• Z-Wave JS driver version is now displayed in config.

I will also be splitting the read me into different pages, for easier reading. i.e. a page for Managed Examples, Unmanaged Examples, Controller Commands. etc etc

I want to start looking at a release for 2.0

I have also deleted the dev branch. any updates should be targeted for the gui release aka 2.0

when we do release it - i will create a new dev branch based off gui which will become main by that time.

[marcus-j-davies]

Have been thinking about your Meter problem. Luckily, a lot of it is read only (apart from resetting the values).

You could just offer up a floating absolute positioned div, to shows its complex structure? I can map the calls via the Managed mode (specifically getAll if needed)

getAll doesn't require any structured payload - Do you have a meter to test?

EDIT. Actually - on reflection, I don't think a floating div is wise, I think it goes against node-red' design principles?

[hufftheweevil]

Okay I've made all the changes I'm planning on making for now.

For the Meter CC, I simply filtered out the previousValue and deltaTime properties and then stored them in data and displayed via a tooltip. So all you see is the main values, then more data if you mouse over.

[marcus-j-davies]

Nice!

I am going to improve one or 2 things before dropping 2.0. have raised an issue for them. 👍