MAP transform for zwave items?

@chris that means the thing definition in zwave is wrong isnt it?

Well, it’s wrong if the documentation is wrong :wink:. Currently, I think the implementation in Z-Wave is inline with the ESH documentation which states that a DOOR and WINDOW category should be a SWITCH.

I’m more than happy to change it if it’s wrong, but in that case we should update the documentation. @kai - are you happy to change DOOR and WINDOW to be CONTACT rather than SWITCH (or as well as SWITCH - maybe switch was there to support locks?). If so, I’ll make a PR on the docs?

I had actually never looked so closely into this category table. Having done so now, I think we should add more item types to a few lines. I think “Door” is actually fuzzy and it is currently a Switch, because it is about being locked and not about being opened. And that’s why it is also RW, since you can lock it through commands.
So for all (Door, Windows, GarageDoor) I would actually allow “Contact” to be a possible item type. And thus for a “door sensor” as the one we talk about here, Contact would be the most natural fit.
@chris: Yes, very happy to accept PRs for the documentation!

Please add Rollershutter as an allowed item type if categories are restricting how to represent a garage door. Is there a document that describes how and why ESH/OH2 imposes constraints like these? I would like to understand the big picture, and how it’s not leading towards problems like Vera has with trying to fit the world into pre-imagined UPnP services.

Thanks for any pointers.

How does the binding know what state to provide for a channel update when there are multiple item types? In OH1, the binding had visibility of the items so could provide a compatible state, but in OH2 we don’t see the item. If the user can have either a ContactItem, or a SwitchItem, then how does the system reconcile this?

It’s obviously fine for commands sent to the binding, so multiple item types is fine in this direction, but when updating a state, shouldn’t there be only one item type? (or am I missing something fundamental - I suspect I must be?).

This leaves many bindings un-port-able to OH2, in that the context of the item is needed to determine how to represent the state update.

I think you are overestimating the importance of this table. It was merely introduced to have a rough categorisation merely for the purpose to be able to render an appropriate icon for it. Bindings have always been free to NOT define any category for a channel and have whatever item type defined for it as it wants - so this table does not put any constraints on the bindings, but rather wants to help them to have a well-suited icon referenced.

If the user can have either a ContactItem, or a SwitchItem, then how does the system reconcile this?

It is not the user, it is your channel type, where it is defined, which item type is the right one. So YOU can decide this, not the user.
If you want to allow the user to have multiple choices for item types, the way to go is to simply offer alternative channels to him.

In some cases, this will mean an alternate channel for every possible type, because the developer won’t have pre-knowledge of a smaller subset.

Yes, but this results in the problems we see now. I “decided” (through use of the table) that a DOOR was a SwitchItem, however others wanted something else… I’m happy to change, and if we don’t need to worry about the table in the docs, then that’s fine by me - Z-Wave users can then decide…

I can do that, but then we end up with multiple channels all doing the same thing which doesn’t seem like a good solution. In this example, we’d have two door channels - one a contact, and one a switch. It just seems that there should be a single channel?

Anyway, for now I’ll update the door to use a contact :slightly_smiling:

How did you solve it in OH1?
Do you check the item type and then have a generic logic of what state update you are sending?

Sooner or later we need to introduce a way to give bindings some information about what is linked to them and how - see also https://github.com/eclipse/smarthome/issues/583. This should only give them access to the item types and the link configuration, not directly item names (to make sure the separation is kept) - but this should bring you all you are asking for here I guess.

Exactly - since the binding has visibility of the item, it can test the item type and provide an appropriate state. In Z-Wave, we have the concept of converters which sit between the Z-Wave command classes, and the OH types - they test the item type, and provide conversions for a number of ‘acceptable’ types.

That sounds fine :).

Better than testing the item type is to simply keep the list of accepted data types for the item, so that the OH1 binding does not end up maintaining a hard-coded mapping of accepted data types for a given item type, since the Item can already provide that list when the binding config is being processed.

Do you mean to provide an update of all data types from the binding, and then let the system link the appropriate type to the item?

I don’t know if you’re asking me, Chris, but here is a comment on the subject from two weeks ago. The point is have the list of accepted data types for the linked item, and post the update in an accepted type, without having the channel constrained to the pre-determined subset of types supported by the channel. The list of accepted types is more appropriately an attribute of the linked item, not the channel, in my opinion.

I was :wink:

But if you do it this way, how do you handle the situation where multiple items are linked to a single channel?

A simple option (if such a thing exist :wink:) might be for the stateUpdate method to take an array of types, and let ‘the system’ decide when it’s linking the items to the channel updates, what best type to provide? This is a bit more work in the binding to provide multiple types, but it will have to do this anyway, and it avoids the need to provide item information to the binding…

I can’t say I have a suggestion about the best way to implement a good solution in ESH, but the key is to have – somehow – the context of the destination item(s) taken into account when the binding is deciding which type to use for the update. Having a pre-determined type for the channel seems too inflexible, unless ESH does some magic under the covers that somehow takes the destination items’ accepted types into account.

Another way to think of it: Channel types shouldn’t define which type(s) are accepted. The accepted State types should come directly from any linked items, so updateState would be responsible for providing an update for each list of accepted types the channel says are needed. If there are no linked items, then there are no lists of accepted types, and therefore no updates. Also, if the update can’t be represented in any accepted data type in one list, then the just doesn’t get updated—the user chose an item type that doesn’t make sense for that channel. A side benefit is that String items are universal recipients, since everything has a string representation. Helper methods can simplify a lot of this for binding authors, like having more updateState method signatures that accept boolean, String, Calendar, BigDecimal, etc., and let the channel figure out which State types are needed to update which items. The <item-type> of a <channel-type> would therefore have no purpose, as it would be determined dynamically.

This gives the user the choice of item types they want to update from a channel without predefined constraints. This would allow every scenario I can think of for preserving the dynamic type handling that OH1 bindings can do.

I think we’re almost saying the same (or similar) - which is good :slightly_smiling:.

I would say the accepted state types should come from the channel definition in the binding. Presumably, the binding author knows best what types are possible. I would say that the binding should provide a conversion for ‘all reasonable types’ that are applicable to a particular channel. There may be a concern here for dynamic data, but at the end of the day, the binding will need to provide a conversion no matter what is done, so it should be able to specify this up front. If the data is truly dynamic, then the binding should provide ‘all’ conversions so that the user has total freedom…

My thoughts are we need to solve the following issues / requirements -:

  1. Allow the user to represent their data in the way they want
  2. Allow the binding provider to know how the data types need to be provided to support the above requirement
  3. Allow the UI to know all of the above so that only applicable types can be set for a specific channel

I would propose something along the following lines…

  • The channel-type definition (both static and dynamic) gets an array of acceptable item types (I think currently this is a single type only). This is presented in the channel-type definition via REST so that the UI can limit selection t the user.
  • The updateState method is overriden so that it can take an array of states. The binding provides a state for each defined type
  • In the core, the part of the code that updates items needs to look at the item type, and set the best state that’s applicable to the item.

I think doing it this way means the binding doesn’t need to get passed a list of item types. In any case, the binding needs to be capable of providing the conversion(s), so I think it seems simpler to just have the binding provide all applicable states rather than just the ones that might be used at any time.

I suspect providing a list of required item types to the binding could get complex since this could change ‘dynamically’ - and given the binding already must provide the code to do the conversions, it doesn’t seem necessary (to me :wink:)… Given that most conversions are probably one line of code just to cast the state to the correct type, I don’t think the extra overhead should be an issue?

I wonder what you think of that? Maybe your use case is different - do you think any other context information is required from the item definition other than its type? I know there is the issue above that Kai referenced to pass more properties to the binding, but as I commented in that issue, I don’t think (in most instances anyway) that’s the best place to put such functionality…

I don’t think that holds in all cases. There is this existing tension now between the channel types and the receiving item types, and a clean solution is to remove the imposition created by channels altogether.

I also think it’s not good to track item types at all, because what you’re really concerned with are the State types that items accept, when it comes time to update state. It’s too much fiddling to say “because this is an X item type, then I can use A,B or C State types.” Just be concerned with the accepted State types in the first place.

I think the majority of cases are more like "my binding has a boolean state, so I call updateState(channel, boolean), and let the channel post the OnOffType.ON, UpDownState.DOWN, OpenClosedType.CLOSED, etc., as the linked items expect. Maybe some bindings would override these default translations, but most wouldn’t I don’t think.

This discussion clearly needs to be moved over to ESH - I see your points, but I would also like to stress that the current setup worked pretty well for many bindings already, so I think it is a valid “default” way of doing things and we can discuss what extra additions we might want to have for other situations.
FTR: At least some of what is discussed here is continued at https://github.com/eclipse/smarthome/issues/583.