No, it is still there: I applied the bitmask again and I applied an advanced tag to the parameter without a bitmask (you can change this parameter after you’ve set the advanced mode in HABmin) :
Although we normally don’t add parameters which are not in the manual I approved this
Please (!) report back if the parameter works on this device or not.
Merging make take a while as Chris is on vacation.
I have set a reminder in my calender to otherwise remove this parameter in four weeks.
Thx.
I tested out two values this morning on my LZW30-SN switch and they worked (Red blinking and Green Blinking)
I believe he is away for 2 weeks without a working VPN.
1 Like
I’ve just installed two of inovellis new dimmer switches which just became available a few days ago.
I see someone has just added the dimmer to the database 12 hours ago, but I assume we also have to wait for Chris to be able to use these, is that right?
That is correct. The database is part of the binding. Chris is away on vacation until late next week. I would guess he will export the database at the end of next week.
After the build system picks up the changes you will then need to upgrade the binding to the snapshot version. Finally you need to delete and rediscover the Things.
No, the device is available since 20190930 in the database:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1118
and has been merged into the binding on 20191003:
https://github.com/openhab/org.openhab.binding.zwave/blob/master/src/main/resources/ESH-INF/thing/inovelli/lzw30_0_0.xml
1 Like
In that case they need to manually update their binding preferably using the script.
1 Like
Thanks for the reply guys.
This is a new v2 edition of the dimmer, just released this week. It’s a completely different model: LZW31-SN
I’ll wait for Chris to update the binding. just wanted to confirm. Thanks!
Please post your xml & a pdf of the manual. There are people other than Chris that can update the database but, AFAIK, only Chris can export it to OpenHAB.
This thread is about the LZW30, though.
The LZW31 is available in the database, but has not yet made it into the binding:
Next time please open a new thread.
1 Like
Sorry for the confusion. Will open a new thread next time, thanks!
1 Like
I did not see that in the thread title. I see it is for new Inovelli switches.
I was referring to the first post (which is the LZW30):
Relevant at least to some extent to all the new inovelli switches is this response and tool.
Replying in regards to the discrepancy on the light flash mode, Eric, from Inovelli, responded:
Hi, the reason for the discrepancy there is that the switch [edit LZW-30] actually doesn’t have a “strobe” function (the dimmer [edit LZW-31]does), so I think I was messing around with that option and haven’t finished it. We actually had a community member create a much more useful tool though.
I’m in the process of asking him to make one for the dimmer (since it is such a great tool).
I’ve added a link to this in the description for parameter 8 in the LZW30-SN device in the zwave database, so eventually it will be up front and accessible for anyone with the device installed/active in their system.
Hope this helps!
Ben
2 Likes
I’m curious…what’s the proper way to be setting the LED value for these? I tried setting param8 via an update, but that didn’t seem to do anything. I’ve since just made it work by setting the individual config endpoints using the API calls in a rule, but that’s certainly not ideal.
@bdm maybe you have an idea?
I have the onboard LED working through the parameter item exposed by the zwave binding. Here is a sample items file and rule to go with it:
zwave.items
Switch KitchenDoorLightsStatus "Kitchen Door Lights" (outdoors,Lights,ExtLights) {channel="zwave:device:057c652b:node3:switch_binary"}
Number KitchenDoorLightsWatts "Kitchen Door Lights Watts" (outdoors) {channel="zwave:device:057c652b:node3:meter_watts"}
Number KitchenDoorLightsScene "Kitchen Door Lights Scene" (outdoors) {channel="zwave:device:057c652b:node3:scene_number"}
Number KitchenDoorLightsEffect "Kitchen Door Lights LED Effect" (outdoors) {channel="zwave:device:057c652b:node3:config_decimal_param8"}
lighting.rules
//Configuration values from https://nathanfiscus.github.io/inovelli-notification-calc/
KitchenDoorLightsEffect.sendCommand(83823231) //set switch indicator to cyan pulsing
KitchenDoorLightsEffect.sendCommand(83823105) //set switch indicator to red pulsing
1 Like
I was inspired from some posts on the inovelli forum to come up with unique ways use these awesome switches. This particular rule changes my kitchen counter lighting colors when you hit the config button on the switch. It reads the current color of the onboard LED and scrolls through 4 different color choices (simultaneously matching the color shown by the onboard LED).
(crossposted on inovelli boards too)
zwave.items
Number KitchenDoorLightsScene "Kitchen Door Lights Scene" (outdoors) {channel="zwave:device:057c652b:node3:scene_number"}
Number KitchenDoorLightsEffect "Kitchen Door Lights LED Effect" (outdoors) {channel="zwave:device:057c652b:node3:config_decimal_param8"}
lighting.rules
rule "Kitchen Counter Lights"
when
Item KitchenDoorLightsScene changed
then
val String KitchenDoorscene = KitchenDoorLightsScene.state.toString
var String KitchenCounterColorCur = KitchenDoorLightsEffect.state.toString
val hueActionsColorLocal1 = getActions("hue","hue:0210:1:bulb1")
val hueActionsColorLocal2 = getActions("hue","hue:0210:1:bulb4")
var HSBType color = new HSBType(new DecimalType(0),new PercentType(0),new PercentType(100))
switch KitchenDoorscene {
case "2.0": //1x tap up
{
Kitchen_Counter1_Dimmer.sendCommand(100)
Kitchen_Counter2_Dimmer.sendCommand(100)
}
case "2.3": //2x tap up
{
}
case "1.0": //2x tap down
{
Kitchen_Counter1_Dimmer.sendCommand(0)
Kitchen_Counter2_Dimmer.sendCommand(0)
}
case "1.3": //2x tap down
{
}
case "3.0": //config button
{
logInfo("Kitchen Counter Color Change", "Current color " + KitchenCounterColorCur)
switch KitchenCounterColorCur {
case "83823231": //cyan pulsing (default)
{
color = new HSBType(new DecimalType(36),new PercentType(100),new PercentType(100)) //orange
KitchenDoorLightsEffect.sendCommand(17107499) //set switch indicator to yellow solid for 5s
}
case "17107499":
{
color = new HSBType(new DecimalType(199),new PercentType(100),new PercentType(100)) //blue
KitchenDoorLightsEffect.sendCommand(17107619) //set switch indicator to blue solid for 5s
}
case "17107619":
{
color = new HSBType(new DecimalType(120),new PercentType(100),new PercentType(100)) //green
KitchenDoorLightsEffect.sendCommand(17107536) //set switch indicator to green solid for 5s
}
case "17107536":
{
color = new HSBType(new DecimalType(30),new PercentType(64),new PercentType(100)) //default
KitchenDoorLightsEffect.sendCommand(83823231) //set switch indicator to cyan pulsing
}
default:
{
color = new HSBType(new DecimalType(30),new PercentType(64),new PercentType(100)) //default
KitchenDoorLightsEffect.sendCommand(83823231) //set switch indicator to cyan pulsing
}
}
//execute lamp color command
hueActionsColorLocal1.fadingLightCommand("color", color, new DecimalType(1000))
hueActionsColorLocal2.fadingLightCommand("color", color, new DecimalType(1000))
}
}
KitchenDoorLightsScene.sendCommand(99) //reset to neutral
end
1 Like
@feens, I think @roy_liao has answered this much better than I could .
Thanks Roy!
(I look forward to getting my notifications-capable switches to try these out myself, or at least until chris returns from vacation and pushes the updates to the LZW30 to see if the LED notifications on it work as I hope they may)
Ben
Hope it helps!
BTW, do you mean the dimmers (LZW31)?
The switches (LZW30) are already working with the latest zwave binding. The rule above was written for an LZW30.