Closed hufftheweevil closed 3 years ago
@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?
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
Can you see much more being done for 1.4? the list todate,
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?
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,
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.
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:
Unmanaged
operation GetValueMetadata
that does just that.Controller
operation SetNodeName
that does just that.More info and a demo to come soon!
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/
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.
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.
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!
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.
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) .
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.
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
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
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
@hufftheweevil,
I'm going to start pushing some updates into the gui
branch.
Have just pushed some.
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.
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?
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.
Nice!
I am going to improve one or 2 things before dropping 2.0. have raised an issue for them. 👍
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:
If you have suggestions, ideas, comments, please post them here.