[feat] API to issue getValue for a single value

[LordMike]

Is your feature request related to a problem? Please describe.
On topic with the polling we're discussing elsewhere, perhaps an API to getValue for a single thing? :)

There is refreshValues right now, but it's probably too much if just one value is desired.

Describe the solution you'd like
Add a getValue API accepting the node, cc, endpoint and index (and possibly partial value). F.ex.:

[12, 112, 0, 1, 8]

.. for Node 12, cc 112 (configs), endpoint 0 parameter 1, partial value 8

Should the getValue work on partial params?.. You could ignore that, and just operate on the whole value - I expect the partials are updated when the full value is updated.

The MQTT topic could be in the api part, but it could also make sense to place it with the published values. Much like targetValue has a /set, you could make currentValue have a /get or /refresh.

I've used configuration as example. What I'm really interested in is a meter reading.. But I suppose the same solution applies to configurations, multilevels, switches, etc..

Describe alternatives you've considered
N/A

Additional context
N/A

[robertsLando]

@LordMike Is the getValue api available in zwave-js? I didn't saw it

[robertsLando]

@LordMike If you mean https://zwave-js.github.io/node-zwave-js/#/api/node?id=getvalue, that only fetches the value from the cache and doesn't refresh it

[LordMike]

I didn't check if an api was available. I was hoping the refreshValues had a variant that allowed for a single value to be refreshed.

[AlCalzone]

zwave-js/node-zwave-js#1479 adds support for this.

[robertsLando]

@AlCalzone Requires new release right?

[chrish987]

would you consider adding a more synchronous type interface than mqtt for value query? mqtt is great for async and unsolicited notifications but for value query a REST sync interface would be great. I think that really the zwave software should be the master for any zwave sourced values, and given the nature of many zwave sensors (e.g. battery temp sensor) being able to retrieve the 'last known' value synchronously is very useful instead of having to fire an async query that will try and query the device. I know you recently added the correlation value to the mqtt api response and this does mean these requests can be done over mqtt, but i think REST would be better.

example use case:
a light turning on after a PIR sensor trigger but only under certain light conditions. mqtt is great for the PIR notification and the light ON command, but being able to query the last value of the LUX sensor synchronously is better, and a stored value from the last zwave poll would be fine for this.

[robertsLando]

a light turning on after a PIR sensor trigger but only under certain light conditions. mqtt is great for the PIR notification and the light ON command, but being able to query the last value of the LUX sensor synchronously is better, and a stored value from the last zwave poll would be fine for this.

Why should use rest apis be better then this? Also there is zwave-js-server now that is integrated with zwavejs2mqtt and you can even use websocket for that

[chrish987]

Is there an API available via MQTT to just query a value from cache (I guess the getValue this thread started with)? not all use cases want to poll the node - which may take time to respond.

Do you have any more information about the zwave-js-server, I have had a read of the github page but the documentation is quite sparse. Does it support HTTP query or just websocket?

You have some status available for the health of zwavejs2mqtt available via an HTTP GET, could a simple value from cache not be exposed in the same way?

[robertsLando]

Do you have any more information about the zwave-js-server, I have had a read of the github page but the documentation is quite sparse. Does it support HTTP query or just websocket?

Just websocket

could a simple value from cache not be exposed in the same way?

I still don't get where is the problem here. I mean there are MQTT and Websockets already for this

[chrish987]

any thoughts on adding the getValue API to mqtt?

[LordMike]

@chrish987 does it make sense?

Want to get a value over z-wave? Use pollValue(); Want to see a cached value? Read the relevant topic, if the values are retained (mqtt setting), they're always there.

[robertsLando]

@chrish987 The getValue api has no sense, it fetches the value from cache and that's the same that is sent in mqtt. Like @LordMike suggested maybe you are looking for pollValue

[chrish987]

I understand the difference between pollValue and getValue.

Currently I don't have retain turned on, as I don't think this works for all types of update (I have raised another ticket to request this as an enhancement to configure per gateway item).

What I am trying to achieve is an architecture where device values are mastered close to the source - and the closest is in the zwave software. The master of the values needs a mechanism to retrieve the value, even if it is an 'old' value.

I agree retain setting in MQTT would allow values to always be queried from there - but using a message broker as a master of device values does not seem like a good architecture. Likewise HomeAssistant can master the values, but I am using HA as more of a GUI and interface. Some values (e.g. illuminance from a sensor) are very useful to drive workflows, but not interesting for a person to actually 'see' - so not much value in sending to HA.

Previously I was using HomeSeer as the zwave software, with NodeRed for workflow/orchestration, and HA for display/control. I am trying to not persist any data in NodeRed, and only send to HA what is interesting to a user. HomeSeer was always the master of the configuration and any value data from the zwave network.

I assume this is a fairly easy feature as the API is already exposed in zwave-js? Let me know if you definitely don't want to add this feature - and then I will stop replying to this closed ticket :)

[robertsLando]

@chrish987 INstead of exposing that api I would prefer to fix the things that should not be retained. MQTT retain is once of the features that make mqtt the perfect protocol for iot (along with the topic structure and more)

Also what I plan to do is to make the qos and the reatin flag configurable from gateway values table (you find it on general or gateway section based on the version you are running). With both this solutions you can do all you want

[LordMike]

@chrish987 you can also get the current values, iirc, with the getNodes() api's, as a workaround. If you access the node id you want, you should find a values property with a dictionary/map of each value the node has.

It's a lot of data.. 100's of KB... but it should work.

[chrish987]

ok. sounds good. thanks.

I had seen the getNodes() - but as you say a lot of data to just get 1 value :)