Maybe this helps
According to the german user manual for ARZ ZWave on page 3. It consists of 3 endpoints.
Complete down
Complete up
protective switch (if someone touches it or any other kind of)
There is nothing written about explicit positioning.
For sure you can operate it with the Fakro remotes as (ZWK, ZWG, ZWP10 or other similar 3rd party products) and stop it at a certain level (manually).
So my guess would be to control the positioning not with shutters itself but through the switches that control the shutters, and those should probably also report the position therefore, but it’s really just a guess.
Definitely agreeing with Smhaller on this authentic free google play codes list. Your setup should understand whether the shutter is shutting down or stopping the motor.
@chris I am now confident that the ARZ roller shutters I have are missing in the Z-Wave database. I suppose the incorrect assignment to ZWS12 may be a result of a lack of version selectivity (the ZWS12 currently in the DB applies to “all” versions of 3 references).
My shutters have a manual issued in 2013, whereas the original ARZ shutters have a manual issued in 2011. The ARZ Solar and “ARZ 1.1” roller shutters are no match either.
The ZWS12 report LIB_SLAVE_ENHANCED while “my” ARZ roller shutters report LIB_SLAVE_ROUTING.
Would it be possible to add “my” ARZ roller shutters, being selective on the application version (v2.01)? I’d call them “ARZ (2013)” as opposed to the current “ARZ” issued in 2011.
I just uploaded the XML but the database assigns it to the existing ZWS12 entry. Probably because the ZWS12 entry is overruling any new entry because it claims to support all firmware versions…
Won’t I destroy the existing ZWS12 entry if I edit it so it fits the ARZ (2013) data?
@chris could you please cancel my XML upload as it will only increase the mess.
I have not read the entire thread, but ti sounds like there are two devices with the same manufacturer/type/id? If so, set the existing (older) device with the max firmware version it supports, then create an entry for the newer device with a min > than the older one.
The problem is that I have no clue about the max firmware supported by the existing devices assigned to the ZWS device record in the Z-Wave DB as the DB entry reports compatibility for “all” firmware versions (with no visible trace of specific firmware versions supported by the binding).
Bottomline: this basically means that I cannot add “my” device as it will inevitably break existing device bindings.
In the future, I would recommend treating the versions more selectively to avoid this type of problems.
I’m not sure I understand your problem. As @5iver said, change the max version in the existing device to something lower than your version, and create a new device.
The binding DOES treat versions selectively - that is one of the criteria it uses to decide the thing type. We always set the max version to maximum so that any new versions that come along will at least be supported with the old functionality. To get new channels, we would need to add a new entry, but at least it works.
I suggest to take a look at the database guide which states the following -:
Most devices don’t use the firmware version, but some devices have different firmware versions with different features in the same device. The database handles this by introducing a new device and using a minimum and maximum version numbers that is applicable to the device. By default, a device should be configured with the maximum version to detect all new versions (ie set to 255.255). This means that new devices will work, even if new features are not supported without a database update. When a new device is made available, the existing device should be set to a max version lower than the new device, and the new device min version set appropriately.
If I understand correctly, I now need to edit the ZWS12 entry in order to restrict the supported firmware version. I will then have to request review for the changes to be reviewed and implemented. The problem is that there is also the unwanted consequences of the XML upload on top of the desired / required firmware version restriction edit. I want to avoid creating an unnecessary mess.
Yes, you are correct. In order to solve the XML upload issue, first edit the type/id in the XML to some random numbers. This will ensure that a new database entry is created rather than it just pointing to the existing entry. Once the new entry is created, then edit the type/id back to the correct value and set the versions appropriately.
Uploading the XML as you are doing now will not make any changes to the database, so it’s not creating a mess (yet ).
Endpoint 0 contains both switch and dimmer channels. It probably should only include dimmer!
From my understanding, the SWITCH_BINARYswitch_binary item only tells if the motor circuit is powered. We shouldn’t directly interact with it as the motor operation is controlled directly from the SWITCH_MULTILEVELswitch_dimmer. So my question is whether we should keep the switch_binary exposed.
From the user manual, the switch_dimmer only understands the following 5 commands:
Command
How to enable with the ZWP10 portable remote controller
Fully open
Click the UP button
Fully close
Click the DOWN button
Stop
Click the STOP button
Open (dimmer)
Keep the UP button pressed until the desired roller shutter opening level has been reached
Close (dimmer)
Keep the DOWN button pressed until the desired roller shutter closing level has been reached
To my knowledge the ARZ (2013 revision) does not implement means to set the dimmer level to a specified value (e.g., open 25%).
I have some new information about the problems with the Fakro ZWS 12 windows openers and ARZ shutters.
From both types I have 3 of them, and they identify them self like this in domoticz:
my ARZ deviced identify themselves as:
ID 0x0001 Type 0x0003 ZWS12 (which is in reality and Fakro ARZ)
ID 0x0002 Type 0x0002 ARZ Roof Window, which is correct
my ZWS12 devices identify themselves as:
ID 0x0001 Type 0x0002 Unknow device, which is in reality a Fakro ZWS12
ID 0x0001 Type 0x0003 Fakro ZWS 12, which is correct.
What you can see is that I have both an ZWS12 as well an ARZ, both identifying themselves as ID 0x0001 Type 0x0003.
I think Fakro made a mistake in there firmware, they made 2 different kind of devices identifying themselves under the same type and ID. This is something which can never be solved in OZW, openhab, domoticz, home assistant or whatever. User of these devices need a software update.
Maybe they ran out of Z-Wave modules for the ARZ and used the ZWS12 modules instead? Or maybe there was a batch mix-up one day? It’s defintely not making our lives easier
Below I made a table, what is showing up in openzwave (i’m actually running combination of domoticz and home assistant, since HA was never able to control my fakro devices properly…) On the HA forum people complain about this issue too, but Openhab forum seems most active on this problem. Since it is a general problem, and not openhab specific, it doesn’t matter where it will be discussed.
I’m not sure - it’s all very well to say that it’s wrong, but I don’t want to force people that have been using their devices for a long time to now have to return them. Firstly, people will just see hat the binding no longer works - they won’t find this discussion.
If we can use the application version to differentiate the versions, I think that would be a better solution.
).
