Chris, thanks for your reply.
Openhab version is 2.1.0. I’m using openhabian. Tried to restart the system - same case. Do i need restart binding via openhab console?
But this is known then - it says it’s a TZ68 wall plug, so it knows the device. You now need to add it in as a thing for the initialisation to complete…
Yes, it says it right in inbox label. So, openhab discovered thing type of device. But thingTypeUID is unknown (zwave:device). Is it ok?
I’m using rest API to control openhab from another application, that’s why i need to know thingTypeUID.
Yes - this is fine. The thing type is set after the device is instantiated.
You can’t guarantee that this is constant. The thing type can change (and does change) after the thing is instantiated. You need to create the thing, and then you can get the thing type UID.
BTW This is also why there is a thingUID and a thingTypeUID. In the early days, the thing type UID was embedded as part of the thing UID. This was changed to allow dynamic thing types. The thing UID will remain constant - the thing type can change at “any” time (in theory at least).
I don’t understand. If ZWave binding discovered type of thing, how can it be changed? Wrong discovering? Yes, openhab allow to change thing type dynamically, but why not to set discovered thing type?
I explain the problem, of external application using openhab rest API. User want to add new device, he know the device type, so he choose it from drop-down menu (TZ68 socket). But after discovery command, there are few devices in inbox. How to choose right one? (TZ68)
You need to understand how the system works. When a device is added to the inbox it is not necessarily fully discovered. It might be still unknown, so the binding adds this as a temporary device until discovery is complete. ZWave binding handles this in two stages for this reason.
But the user can not change the device type - it’s fixed . How can they select this?
The name of the device is given. The node number is given. As above, if the device is not fully discovered yet, only the node number is provided. If they add a new device, then they will see this device immediately in the inbox - they should know this was just added.
I mean I allow user to choose device type of device he want to add. From all available zwave device types. That’s why i need to associate choosen device type to discovered thing.
Yes, for now it’s alternative for me to not allow user to choose device type. Just show him all discovered devices and allow to choose needed device to add.
If unknown thingTypeId of inbox thing is OK, so let’s close the topic. Thanks for your reply!
I still don’t understand this. The device type can not be changed - it is read from the device and the user can not “choose” a different one. Maybe I just misunderstand what you’re doing (sorry if so).
Just to add a bit more ‘flavour’ - the discovery was done this way to allow the system to cope with different scenarios. In your case, you want to know this before the device is added as a thing - in other instances, people will add the thing before the type is known (eg if the auto inbox include option is selected, then as soon as a thing is added to the inbox, it is automatically added as a thing). To support both cases isn’t impossible, but is also not straight forward…
Yes - it’s currently how it works (of course if you want to improve this, please feel free ).
Let’s imagine, the external application know all device types.User want to add the device and he know which one to add.
The application allow user to choose the device type of adding device (like TZ68 socket).
User choose the device type.
The application start discovery and find inbox with the given thingTypeId.
Yes - it’s currently how it works (of course if you want to improve this, please feel free ).
You mean I could change the sources?
Is it possible to add discovered thingTypeId as new parameted in json of rest service?
I still don’t understand your use case - sorry. When you add a device - if you only add one device - you know exactly what it is. It also doesn’t stop you adding a different device since the inclusion is in no way linked to a single device… There is no way to say “I only want to add a TZ68” - it’s not possible to do this with ZWave. As soon as it’s in the inbox, then you know what it is, and you can’t change it.
Of course - if you like. What we are talking about though is not trivial for the reasons I stated above. If you no longer want to remain compatible to OH, then you might be able to do something slightly simpler that suits your need though.
I guess you mean in the inbox interface? For the reasons I said above, the big problem is that the discovery may happen after the thing is already instantiated as a thing. This information is not available as part of the inclusion - it comes later (potentially much later depending on the device) - so you always need to cope with the situation where this isn’t known (really - always).
I explain.
User choose “TZ68” to add.
The application starts discovery and find few devices.
After that inboxes contain information about the device (i mean it makes the inbox label as ‘Z-Wave Node N: TZ68 Wall Plug’). But not contains really thingTypeId (currently as ‘zwave:tkb_tz68_00_000’), it contains thingTypeId = zwave:device (unknown).
So, if inbox would contain real thingTypeId, the application will able to say “dear user, the device TZ68 was found”.
For now it’s impossible.
So, tell me please, how the openhab set label of inbox to the real device type? (‘Z-Wave Node N: TZ68 Wall Plug’)
I think the thing-type is available as part of the inclusion. I just need something like new parameter in rest service json - /rest/inbox.
Like: …, “expectedThingTypeId”:“zwave:tkb_tz68_00_000”, …
Would it be possible?
Ok, understood, but this is NEVER guaranteed. As I said earlier, the device information is NOT provided as part of the inclusion - it comes later. This might only take a few seconds, or it might take much longer - depending on the device. So, you MUST handle the situation where the device type is not know. The other option is that devices are not added to the inbox until after this second stage of the discovery is complete. However, IMHO, this is a bad idea since then you must handle the situation where there is nothing in the inbox until this second stage completes. This is very likely to confuse the user.
I hope that helps to explain why the system works like it does.
No - as said already, it definitely isn’t. As explained above, this comes later and you must therefore be able to handle the situation where this information is not available.
ESH has the ability to update the inbox information. So, the ZWave binding initially adds the device into the inbox without this information. This is done so that when the user adds a device, they don’t have to wait for the manufacturer information to be found. Then, later when the device information is known, and we know the device type, the name is updated.
Another thought - how would you handle devices that aren’t known at all (ie devices that aren’t in the database). They wouldn’t show at all…
Thank you, Chris, for this explanation! This is very helpful information. Some devices really takes a lot of time to show device information. I’ll handle this cases.
Tell me please, does the device information comes ALLWAYS (right now, after 1 min, after 1 hour) to inbox thing? Or the device could be UNKNOWN in inbox and will be initialized after adding to things?
. How can they select this?
).