I have installed DWZWAVE25 and WADWAZ-1 door/window Z-wave sensors, and am just now getting round to writing rules for them. What I have found is the DWZWAVE25 devices report ON/OFF while the WADWAZ-1 reports Open/Closed.
This begs the philosophical question of what it should be, but I’m more interested in how to resolve.
I could go and submit a database ticket to have the “generic” “sensor_binary” changed to “sensor_door”. The problem here is that this will break rules other people have already written for the device.
I can add virtual switches in my configuration, which I have done. As far as I can tell, using the mapping in sitemaps doesn’t work because the logical item type is of Contact vs Switch.
So, what is the best way to solve this? I would really like to be able to transform or map thing channels in my items file. Is there a way to be able to use these items in my rules without making virtual items and special rules?
The channels should be updated so that they properly support the notifications.
The question about wether they should be contacts or switches is not a zwave discussion since it is applicable to all bindings. Recently there have been some more system channels added and probably the binding should be changed to use them, however it won’t really help your question since there isn’t a door channel yet.
The current definitions used in the binding are as per the original statement about item types in ESH - as above, this should not be decided by ZWave.
What I would propose for both devices is to change the SENSOR_BINARY class to use sensor_binary channel, and then use the sensor_door and alarm_tamper on the two notifications. This would make these devices more standard.
Yes - my point was to make the two the same, but I wasn’t so clear…
Yes - I don’t think alarm_burglar will do anything at all in 2.4 with this device. This channel is linked to the intrusion notifications and not the door sensor notifications.
For the WADWAZ, I was using it as a reference, it is working for me. I don’t see anything in the database of binary_sensor to deprecate. I’m trying to not make a fool of myself, but I don’t understand your comment.
I’m looking at the JSON formatted data on your website, as it seems to have all of the information. How should I contact you to ask for database edit rights? I do have an account.
Update: You mean SENSOR_BINARY command class. I also assume that’s what CC means.
Yes it does. A map file can be used in the part of a Contact Item’s label. Or a Contact Item can be presented as a Switch type in a sitemap, with mappings= to produce a button effect. The buttons won’t have any effect, of course.
This simply means that we should be using the notification channels. Instead of just deleting the other channels, the database can mark them as deprecated which means that one day, we’ll delete them, but for now they are still available (one day = about a year).
Yes it does. A map file can be used in the part of a Contact Item’s label. Or a Contact Item can be presented as a Switch type in a sitemap, with mappings= to produce a button effect. The buttons won’t have any effect, of course.
So I must be doing something wrong.
I am using the DWZWAVE which identifies as Switch. I need it to be a Contact.
sitemap:
Default item=DoorSlidingSwitch
Default item=DoorSlidingContact
Contact item=DoorSlidingSwitch mappings=[OPEN="ON",CLOSED="OFF"] // does not compile
contacts.map:
OPEN=ON
CLOSED=OFF
items:
Switch DoorSlidingSwitch "Sliding door switch is [%s]" (gDoorSwitches, test) { channel = "zwave:device:d8092b29:node11:sensor_binary"}
Contact DoorSlidingContact "Door Sliding Contact is [%s]" (gDoorSwitches, test) { channel = "zwave:device:d8092b29:node11:sensor_binary"}
Contact DoorSlidingContactMapped "Door Sliding Contact Mapped is [MAP(contacts.map):%s]" { channel = "zwave:device:d8092b29:node11:sensor_binary"}
rule:
when
Time cron "0 * * * * ?"
then
logInfo("Logger","DoorSlidingContact " + DoorSlidingContact.state + " " + (DoorSlidingContact==OPEN))
logInfo("Logger","DoorSlidingSwitch " + DoorSlidingSwitch.state + " " + (DoorSlidingSwitch==OPEN))
logInfo("Logger","DoorSlidingSwitchMapped " + DoorSlidingSwitchMapped.state + " " + (DoorSlidingSwitchMapped==OPEN))
end
and the results:
2019-01-13 14:35:01.773 [INFO ] [clipse.smarthome.model.script.Logger] - DoorSlidingContact NULL false
2019-01-13 14:35:01.779 [INFO ] [clipse.smarthome.model.script.Logger] - DoorSlidingSwitch OFF false
2019-01-13 14:35:01.783 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Switch Vs Contact': The name 'DoorSlidingSwitchMapped' cannot be resolved to an item or type; line 9, column 51, length 23
So, what is the best way to solve this? I would really like to be able to transform or map thing channels in my items file. Is there a way to be able to use these items in my rules without making virtual items and special rules?
I want to use the mapped items in rules. I have a doors group, and all members of that group need to be the same type, hence my original statement that I’d like to do a map in the Item. I did make virtual contacts that have a rule just to manipulate them according to the Switches as self-identified by the ZWave Items. This works, and is better at least for me, because the sitemap approach seems to apply to presentation rather than implementation.
It seems like this is a problem that is never going to go away completely. Has it been discussed a way to transform one type of item to another, perhaps in the binding braces? One would also be required to supply the map.
I’m an OH novice, so I may be missing something. I’m willing to learn.
Update: I just saw your last comment. I’m checking that now.
Oh, I read that post several times because it kept coming back as results in my searches. It is exactly the problem I have, and the OP solution is exactly what I implemented.
It’s a philosophical debate as to what it should be and can’t be determined at compile time – meaning by the ZWave (or other) database maintainer. I never used OH1, but apparently OH1 allowed one to remap one type of Item to another type of Item.
So, as far as I know, the workarounds require virtual items and rules as proxies to the proper types, or working in the sitemap and parsing values as strings, or remapping there.
There is probably a developer discussion somewhere that discusses this issue. It used to be in OH1, and it’s not in OH2, so someone must have discussed it, or maybe it’s on the OH2 roadmap. I haven’t discovered this discussion yet.
Absolutely correct.
he formatting in the Item “label ” section has something of an oddball or magical power though, it gets used in non-sitemap ways as well.
Here’s an old, but useful discussion. In OH1 bindings, the author could provide features to “map” say a binary input to a Switch or Contact Item.
In OH2 things/channel world, this is no longer so easy.
I understand profiles should address this restriction. New for 2.4, I don’t know how extensive the implementation is yet.
No - I used the original item/channel types that were original stated in the ESH documentation. As I’ve stated earlier, OH is meant to be system agnostic, so ALL bindings should do the same thing, and the only way that this can happen is if everyone follows a single set of guidelines. I suspect that is not happening, but there were guidelines at one point, and that’s what I followed.
Well OH1 was very different. In OH1 the user can specify whatever type they like, and the binding can get this information. In OH2 the binding doesn’t know anything about the items that the user configures, so we have to choose a single type and not allow the user to specify it.
Personally, I don’t mind changing everything if there are new guidelines and channel types etc - although it would be a major task to do so as there are nearly 1000 devices in the database!
Well, yes. If I sit here today, and write my FOOBARomatic system that repurposes the WADWAZ device to use the magnetic sensor for door OPEN/CLOSE, that means what it means. One year from today, I want to repurpose that switch with a magnetic float, and it needs to mean FULL/EMPTY. There’s no way for me to predict the future, nor you, the ESH guys, or even the ZWave company. Like you said, as long as everyone agrees to the same thing, it works. We wouldn’t be having this thread if I didn’t have Contacts and Switch items show up on my doors.
the programmer in me thinks the binding should stay as stupid as possible, and report 1/0, and let the Item handle what to do with that information. It does make the code more verbose. This is going to be an ongoing discussion, I can feel it now.
Sorry - I’m just confused now. My point was simply that I was following the guidelines - I don’t really know what you mean here?
But that’s not how OH/ESH works. We have to turn the 1/0 into a type - a switch, or a contact, a string, or a number etc so that it can be used by users. This is the level of abstraction defined by the system.
I meant that the creators cannot possibly know what the end user will use a device for. If the user wants to use a door switch as a rain gauge, push that detail down on him. Otherwise, if he wants to use it as intended, build out the proper boilerplate that works, or let the user override the default. And by user I’m not talking about you, I’m talking about me.
It feels like one of those dead horse topics, like Star Trek vs Star Wars. In six months someone else is either going to bump this thread or start a new one.
You can use the device for something else - just map the type to something else, or display it differently…
As I said, the system is designed around a specific concept, and bindings need to work within this concept. This is a fundamental point with OH so that all bindings look the same to the user (and yes, that’s you, AND me ).
).