Lutron ZigBee 4-button switch compatibility? 2016-03-14T22:10:10+00:00

HOME Forums Software iSmartenit Lutron ZigBee 4-button switch compatibility?

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • Anonymous
    Post count: 19
    #40488 |

    Hi, I recently purchased a ZigBee Lutron Connected Bulb Remote Control, thinking to use it with my ZigBee GE lightbulbs and the excellent Smartenit gateway on my Raspberry Pi. Here is the website detailing the device:

    http://www.lutron.com/en-US/Products/Pages/Components/ConnectedBulbRemoteControl/Overview.aspx

    After some experimentation, I did get the remote connected to the gateway, but there are a few problems with it. First, I cannot rename it from the default Device (LZL4BWHL01 Remote). Also, there do not appear to be any controls in the iSmartenit UI for this device. But what I’d really like it to do (of course) is be able to control other devices using scenes and wizards, but it does not appear in the list of scene controllers. I would be happy to work through the REST API of the g/w, or examine logs on the g/w to troubleshoot. Holding down the button on the remote to keep this sleepy device awake doesn’t seem to make a difference.

    Note: I can pair the remote directly with my lights using ZLL Touchlink since my lights and the remote both support the ZLL Commissioning cluster but this is communicating with them directly and ignoring the coordinator (RaspPi g/w) which is not what I want.

    Thanks for any help. 🙂
    😀

    Details –
    App:
    Version: 6.32.18
    Mac OS 10.11.3

    Also use App:
    Version 6.32.19
    iPhone OS 9.2.1 iPhone7,1

    Gateway:
    Version: 2.0.9-1
    Type: RaspberryPi

    Anonymous
    Post count: 259

    Hi,

    The Lutron ZigBee 4-button switch is not compatible with the iSmartenit App, which is why you are not able to configure the Links in that device.

    I have submitted an internal request for adding compatibility for this device (should be very easy).

    Sounds like you were able to add the device properly to the gateway, so in the meanwhile you can create Wizards with the REST API. Let me know if you need help with that.

    Anonymous
    Post count: 19

    Thank you Dhawal for your prompt reply. 🙂

    Please excuse me if this is a very basic issue with something obvious I am missing – I have just started looking at the REST API for this. When I query it there are no capabilities associated with it:

    james:~ darren$ curl http://cush:50334/devices/61383/capabilities -XGET
    { "components" : [ ], "id" : 61383, "image" : "default.png", "model" : "LZL4BWHL01 Remote", "name" : "Device (LZL4BWHL01 Remote)" }

    This is not surprising since as you said there is no compatibility for this device. However, I am also showing no capabilities for my GE lights, which I can control from the iSmartenit App just fine:

    james:~ darren$ curl http://cush:50334/devices/42015/capabilities -XGET
    { "components" : [ { "capabilities" : [ ], "id" : "comp1" } ], "id" : 42015, "image" : "default.png", "model" : "ZLL Light", "name" : "ZLL Light" }

    I am assuming that to create a wizard (or Action as it looks like it is called in the API) I have to map the condition of the remote to an effect on the light (such as device/42015/OnOff/toggle), but not being able to see the capabilities of either device has me stumped as to what to put into the creation of the action …

    It makes me wonder if I have to authenticate somehow to be able to see the detailed capabilities of the devices? The API documentation doesn’t hint at that, it’s pure speculation on my part.

    Thanks,
    😀

    Anonymous
    Post count: 259

    I am assuming that to create a wizard (or Action as it looks like it is called in the API) I have to map the condition of the remote to an effect on the light (such as device/42015/OnOff/toggle)

    Yes that is correct.

    It makes me wonder if I have to authenticate somehow to be able to see the detailed capabilities of the devices?

    No, authentication API’s are not yet implemented in the latest release. So what you are doing is correct.

    I am also showing no capabilities for my GE lights, which I can control from the iSmartenit App just fine

    After a Zigbee device joins the network successfully, the ZBPServer will try to request detailed information about the device in order to build the capabilities. If the components are empty, then its possible that the device failed to respond to some messages.
    Can you try to rediscover using following:

    curl -X POST "http://cush:50334/devices/42015/capabilities/discover"

    Let me know how it goes.

    Anonymous
    Post count: 19

    Can you try to rediscover using following:

    curl -X POST "http://cush:50334/devices/42015/capabilities/discover"

    Let me know how it goes.

    Here was the initial result of the discover:

    james:~ darren$ curl http://cush:50334/devices/42015/capabilities -XGET
    { "components" : [ { "capabilities" : [ ], "id" : "comp1" } ], "id" : 42015, "image" : "default.png", "model" : "ZLL Light", "name" : "ZLL Light" }
    james:~ darren$ curl -X POST "http://cush:50334/devices/42015/capabilities/discover"
    { "message" : "Discovering capabilities", "success" : "true" }
    james:~ darren$ curl http://cush:50334/devices/42015/capabilities -XGET
    { "components" : [ { "capabilities" : [ ], "id" : "comp1" } ], "id" : 42015, "image" : "default.png", "model" : "ZLL Light", "name" : "ZLL Light" }

    So it did not appear to change anything. After that, I left it for some time (more than 10 mins) just in case it needed to queue up the request and would take a while to update the internal db, etc and then queried it again. Still the same result.

    Interestingly, I have 6 GE lights on this ZigBee network and all 6 showed exactly the same result as above. They did have a components list, but the capabilities list was blank. In fact the only device on the ZigBee network that had a non-blank capabilities list was the coordinator:

    james:~ darren$ curl http://cush:50334/devices/14477/capabilities -XGET
    { "components" : [ { "capabilities" : [ { "Basic" : [ { "get" : [ "channel", "discoverTime", "fwversion", "ManufacturerName", "ModelID" ] }, "status", { "start_network" : [ { "channel" : "uchar" } ] }, { "discover" : [ { "duration" : "uchar" } ] }, "restart" ] } ], "id" : "comp1" } ], "id" : 14477, "image" : "default.png", "model" : "ZBCID Coord", "name" : "ZBCID" }

    In more playing around I connected to cush and looked at the data.db file in the /etc/zbp directory. It is clearly a database file of some sort, and I’d be interested in querying this directly, but even a simple “cat” of that file revealed that there are processors named in that file for the ZLL Light, so I’m not sure why they are not showing up via the REST query … so I kept digging.

    I found the log in a reasonable location /var/log/zbp/zbp.log, and took a look in it, and sure enough there is a wealth of information there. Here is a snip from the log showing the query/discover/query sequence of the ZLL light I did above:

    Mar 15 11:06:54 cush ZBPServer[15767]: Incoming connection.
    Mar 15 11:06:54 cush ZBPServer[15767]: Scheduler:: socket added
    Mar 15 11:06:54 cush ZBPServer[15767]: http_parser:: GET /devices/42015/capabilities
    Mar 15 11:06:54 cush ZBPServer[15767]: Scheduler:: socket removed
    Mar 15 11:07:12 cush ZBPServer[15767]: Incoming connection.
    Mar 15 11:07:12 cush ZBPServer[15767]: Scheduler:: socket added
    Mar 15 11:07:12 cush ZBPServer[15767]: http_parser:: POST /devices/42015/capabilities/discover
    Mar 15 11:07:12 cush ZBPServer[15767]: NodeMgmt::post method called for device 42015
    Mar 15 11:07:12 cush ZBPServer[15767]: NodeMgmt:: Rediscovering device capabilities: id:a41f
    Mar 15 11:07:12 cush ZBPServer[15767]: ZBP_packet:: [TX] (00) Cmd: 0016 len: 04 data: 02 00 16 04 5e a6 5e a6 12
    Mar 15 11:07:12 cush ZBPServer[15767]: Scheduler:: socket removed
    Mar 15 11:07:12 cush ZBPServer[15767]: ZBP_packet:: [RX] (00) Cmd: 1016 len: 05 data: 00 5e a6 01 01 CRC: fb
    Mar 15 11:07:12 cush ZBPServer[15767]: DiscoverDeviceCapabilities:: record: a41f active endpoints: 1
    Mar 15 11:07:12 cush ZBPServer[15767]: DiscoverDeviceCapabilities:: retrieving clusters from ep:1
    Mar 15 11:07:13 cush ZBPServer[15767]: ZBP_packet:: [TX] (00) Cmd: 0015 len: 05 data: 02 00 15 05 5e a6 5e a6 01 11
    Mar 15 11:07:13 cush ZBPServer[15767]: ZBP_packet:: [RX] (00) Cmd: 1015 len: 1c data: 00 5e a6 18 01 01 04 01 01 00 07 00 00 00 03 00 04 00 05 00 06 00 08 10 00 01 00 19 CRC: fe
    Mar 15 11:07:13 cush ZBPServer[15767]: SimpleDescRequest:: ep: 1 inclusters: 7 outclusters: 1
    Mar 15 11:07:13 cush ZBPServer[15767]: DiscoverDeviceCapabilities:: record:a41f input:7 output:1
    Mar 15 11:07:13 cush ZBPServer[15767]: DiscoverDeviceCapabilities:: device a41f, discover sequence completed, now reporting.
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: record:a41f address:5ea6 model:ZLL Light
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Active ep:1 clusters:7
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 0
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 3
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 4
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 5
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 6
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 8
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 1000
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Active ep:1 output clusters:1
    Mar 15 11:07:13 cush ZBPServer[15767]: discoverDevCapabilitiesCallback:: Cluster: 19
    Mar 15 11:07:13 cush ZBPServer[15767]: NodeMgmt::DeviceCapabilities:: json: { “components” : [ { “endpointID” : 1, “name” : “comp1”, “processors” : [ { “name” : “zbbasic” }, { “name” : “zbidentify” }, { “clusterID” : 4, “name” : “Unsupported” }, { “clusterID” : 5, “name” : “Unsupported” }, { “name” : “zbonoff” }, { “name” : “zblevelcontrol” }, { “clusterID” : 4096, “name” : “Unsupported” }, { “clusterID” : 25, “name” : “Unsupported”, “server” : false } ] } ], “defaultName” : “ZLL Light”, “model” : “ZLL Light” }
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /system/opt/usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zbbasic
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zbbasic
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Plugin zbbasic, comp:comp1 Error adding processor. error: 3
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /system/opt/usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zbidentify
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zbidentify
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Plugin zbidentify, comp:comp1 Error adding processor. error: 3
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Unsupported plugin ignored
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Unsupported plugin ignored
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /system/opt/usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zbonoff
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zbonoff
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Plugin zbonoff, comp:comp1 Error adding processor. error: 3
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /system/opt/usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zblevelcontrol
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugins in: /usr/lib/zbp/plugins
    Mar 15 11:07:13 cush ZBPServer[15767]: devicehelper:: looking for plugin: zblevelcontrol
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Plugin zblevelcontrol, comp:comp1 Error adding processor. error: 3
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Unsupported plugin ignored
    Mar 15 11:07:13 cush ZBPServer[15767]: addComponent:: Unsupported plugin ignored
    Mar 15 11:07:13 cush ZBPServer[15767]: createDevice:: Error adding component Upstairs Desk Bulb 1. error: 3
    Mar 15 11:07:18 cush ZBPServer[15767]: ZLL Light:: initiating components.
    Mar 15 11:07:22 cush ZBPServer[15767]: Incoming connection.
    Mar 15 11:07:22 cush ZBPServer[15767]: Scheduler:: socket added
    Mar 15 11:07:22 cush ZBPServer[15767]: http_parser:: GET /devices/42015/capabilities
    Mar 15 11:07:22 cush ZBPServer[15767]: Scheduler:: socket removed

    I have to say, I really appreciate that the ZigBee packet is given in it’s entirety. Even nicer would be a wireshark decode, for both TX and RX, but I see that you at least provide a decode of what zbp understands from what was received. 🙂

    What jumped out at me is that plugins seem to be expected for the processors – and indeed my system did not have either directory the system attempts to look in. In fact a “find . -name *zbonoff* -print” from the root directory shows that there is no file with “zbonoff” anywhere in the name on the system at all. The installation uses a debian repo, so I thought I’d check there. Sure enough:

    darren@cush ~ $ sudo apt-cache search zbpserver
    zbpserver - Implements API to bridge Wifi, ZigBee, INSTEON and X10 networks
    zbpserver-plugin-geoven - ZBPServer PlugIn-template
    zbpserver-plugin-huelight - ZBPServer PlugIn-template
    zbpserver-plugin-insiaszone - ZBPServer PlugIn-template
    zbpserver-plugin-inslevel - ZBPServer PlugIn-template
    zbpserver-plugin-insonoff - ZBPServer PlugIn-template
    zbpserver-plugin-nesthermostat - ZBPServer PlugIn-template
    zbpserver-plugin-nestprotect - ZBPServer PlugIn-template
    zbpserver-plugin-testing - ZBPServer PlugIn-template
    zbpserver-plugin-wemoonoff - ZBPServer PlugIn-template
    zbpserver-plugin-wimessenger - ZBPServer PlugIn-template
    zbpserver-plugin-zbalarms - ZBPServer PlugIn-template
    zbpserver-plugin-zbbasic - ZBPServer PlugIn-template
    zbpserver-plugin-zbdoorlock - ZBPServer PlugIn-template
    zbpserver-plugin-zbelectricalmeasurement - ZBPServer PlugIn-template
    zbpserver-plugin-zbevse - ZBPServer PlugIn-template
    zbpserver-plugin-zbfancontrol - ZBPServer PlugIn-template
    zbpserver-plugin-zbiaswd - ZBPServer PlugIn-template
    zbpserver-plugin-zbiaszone - ZBPServer PlugIn-template
    zbpserver-plugin-zbidentify - ZBPServer PlugIn-template
    zbpserver-plugin-zblevelcontrol - ZBPServer PlugIn-template
    zbpserver-plugin-zbonoff - ZBPServer PlugIn-template
    zbpserver-plugin-zbpowerconf - ZBPServer PlugIn-template
    zbpserver-plugin-zbrelativehumiditymeasurement - ZBPServer PlugIn-template
    zbpserver-plugin-zbsimplemeter - ZBPServer PlugIn-template
    zbpserver-plugin-zbtemperaturemeasurement - ZBPServer PlugIn-template
    zbpserver-plugin-zbthermostat - ZBPServer PlugIn-template

    So I figured I should install all the missing plugins. A quick command of “sudo apt-get install zbpserver-plugin*” and all were put into the /usr/lib/zbp/plugins directory. Now let’s run that same query/discover/query again:

    james:~ darren$ curl http://cush:50334/devices/42015/capabilities -XGET
    { "components" : [ { "capabilities" : [ ], "id" : "comp1" } ], "id" : 42015, "image" : "default.png", "model" : "ZLL Light", "name" : "ZLL Light" }
    james:~ darren$ curl -X POST "http://cush:50334/devices/42015/capabilities/discover"
    { "message" : "Discovering capabilities", "success" : "true" }
    james:~ darren$ curl http://cush:50334/devices/42015/capabilities -XGET
    { "components" : [ { "capabilities" : [ { "Basic" : [ { "get" : [ "ZCLVersion", "ApplicationVersion", "StackVersion", "HWVersion", "ManufacturerName", "ModelID", "DateCode", "PowerSource", "LocationDescription", "PhysicalEnviroment", "DeviceEnabled", "AlarmMask", "DisableLocalConfig" ] }, "status", "ResetToFactoryDefaults" ] }, { "Identify" : [ { "get" : [ "IdentifyTime" ] }, "status", { "Identify" : [ { "IdentifyTime" : "ushort" } ] }, "IdentifyQuery" ] }, { "OnOff" : [ { "get" : [ "state" ] }, "status", "Off", "On", "Toggle" ] }, { "LevelControl" : [ { "get" : [ "CurrentLevel", "RemainingTime", "OnOffTransitionTime", "OnLevel" ] }, "status", { "MoveToLevel" : [ { "TransitionTime" : "ushort" }, { "Level" : "uchar" } ] }, { "Move" : [ { "Rate" : "uchar" }, { "Mode" : "uchar" } ] }, { "Step" : [ { "Mode" : "uchar" }, { "Size" : "uchar" }, { "TransitionTime" : "ushort" } ] }, "Stop", { "MoveToLevelWOnOff" : [ { "TransitionTime" : "ushort" }, { "Level" : "uchar" } ] }, { "MoveWOnOf" : [ { "Rate" : "uchar" }, { "Mode" : "uchar" } ] }, { "StepWOnOf" : [ { "Mode" : "uchar" }, { "Size" : "uchar" }, { "TransitionTime" : "ushort" } ] }, "StopWOnOf" ] } ], "id" : "comp1" } ], "id" : 42015, "image" : "default.png", "model" : "ZLL Light", "name" : "ZLL Light" }

    Eureka! 🙂

    For the remote it was unable to do a re-discover, so I had to remove it from the network and re-add it. Of course the device id changed when I did that, but it now comes up with a lot more detailed capabilities:

    james:~ darren$ curl http://cush:50334/devices/16022/capabilities -XGET
    { "components" : [ { "capabilities" : [ { "Basic" : [ { "get" : [ "ZCLVersion", "ApplicationVersion", "StackVersion", "HWVersion", "ManufacturerName", "ModelID", "DateCode", "PowerSource", "LocationDescription", "PhysicalEnviroment", "DeviceEnabled", "AlarmMask", "DisableLocalConfig" ] }, "status", "ResetToFactoryDefaults" ] }, { "EVSE" : [ { "get" : [ "ChargerStatus", "ChargerFault", "ChargeLevel", "SessionId", "SessionTime", "SessionSummationDelivered" ] }, "status", { "StartCharge" : [ { "ID" : "QByteArray" } ] }, { "StopCharge" : [ { "ID" : "QByteArray" } ] }, { "SetCharge" : [ { "Level" : "ushort" } ] }, "GetStatus", "GetInfo" ] }, { "Identify" : [ { "get" : [ "IdentifyTime" ] }, "status", { "Identify" : [ { "IdentifyTime" : "ushort" } ] }, "IdentifyQuery" ] }, { "OnOff" : [ { "get" : [ "state" ] }, "status", "Off", "On", "Toggle" ] }, { "LevelControl" : [ { "get" : [ "CurrentLevel", "RemainingTime", "OnOffTransitionTime", "OnLevel" ] }, "status", { "MoveToLevel" : [ { "TransitionTime" : "ushort" }, { "Level" : "uchar" } ] }, { "Move" : [ { "Rate" : "uchar" }, { "Mode" : "uchar" } ] }, { "Step" : [ { "Mode" : "uchar" }, { "Size" : "uchar" }, { "TransitionTime" : "ushort" } ] }, "Stop", { "MoveToLevelWOnOff" : [ { "TransitionTime" : "ushort" }, { "Level" : "uchar" } ] }, { "MoveWOnOf" : [ { "Rate" : "uchar" }, { "Mode" : "uchar" } ] }, { "StepWOnOf" : [ { "Mode" : "uchar" }, { "Size" : "uchar" }, { "TransitionTime" : "ushort" } ] }, "StopWOnOf" ] }, { "Basic" : [ { "get" : [ "ZCLVersion", "ApplicationVersion", "StackVersion", "HWVersion", "ManufacturerName", "ModelID", "DateCode", "PowerSource", "LocationDescription", "PhysicalEnviroment", "DeviceEnabled", "AlarmMask", "DisableLocalConfig" ] }, "status", "ResetToFactoryDefaults" ] }, { "EVSE" : [ { "get" : [ "ChargerStatus", "ChargerFault", "ChargeLevel", "SessionId", "SessionTime", "SessionSummationDelivered" ] }, "status", { "StartCharge" : [ { "ID" : "QByteArray" } ] }, { "StopCharge" : [ { "ID" : "QByteArray" } ] }, { "SetCharge" : [ { "Level" : "ushort" } ] }, "GetStatus", "GetInfo" ] } ], "id" : "comp1" } ], "id" : 16022, "image" : "default.png", "model" : "LZL4BWHL01 Remote", "name" : "LZL4BWHL01 Remote" }

    Now when I get a bit more time I will attempt to add an Action based on the capabilities discovered in the remote and tie it to a change in the light state.

    I do wonder why the plugins were not installed by default?

    Regards,
    😀

    Anonymous
    Post count: 259

    Great job finding the issue!

    I do wonder why the plugins were not installed by default?

    Ahh because the installation procedure is to use

    sudo apt-get install zbpserver*

    The asterisk was missing in the RPI how-to. It has been corrected.

    Let me know if you need help with anything else.

    Anonymous
    Post count: 19

    Let me know if you need help with anything else.

    Yes, I guess I do. I’ve been banging my head against this for a bit without knowing exactly what the problem is. I think it comes down to my lack of understanding the JSON. 🙂

    Currently, this is what my action looks like:

    {
    "active": false,
    "conditions": [
    {
    "active": true,
    "id": 57401,
    "name": "ButtonOnPushed",
    "path": "device/16022/comp1/OnOff/get/state",
    "start": 1458269124,
    "val": "On"
    }
    ],
    "effects": [
    {
    "active": true,
    "id": 5427,
    "name": "Turn on Desk Bulb 2",
    "params": {},
    "path": "devices/16645/comp1/OnOff/On"
    },
    {
    "active": true,
    "id": 19401,
    "name": "Turn on Desk Bulb 1",
    "params": {},
    "path": "devices/42015/comp1/OnOff/On"
    }
    ],
    "id": 17694,
    "image": "",
    "name": "Turn On Upstairs Desk Lights"
    }

    And here are the capabilities of the Lutron Remote:

    {
    "components": [
    {
    "capabilities": [
    {
    "Basic": [
    {
    "get": [
    "ZCLVersion",
    "ApplicationVersion",
    "StackVersion",
    "HWVersion",
    "ManufacturerName",
    "ModelID",
    "DateCode",
    "PowerSource",
    "LocationDescription",
    "PhysicalEnviroment",
    "DeviceEnabled",
    "AlarmMask",
    "DisableLocalConfig"
    ]
    },
    "status",
    "ResetToFactoryDefaults"
    ]
    },
    {
    "EVSE": [
    {
    "get": [
    "ChargerStatus",
    "ChargerFault",
    "ChargeLevel",
    "SessionId",
    "SessionTime",
    "SessionSummationDelivered"
    ]
    },
    "status",
    {
    "StartCharge": [
    {
    "ID": "QByteArray"
    }
    ]
    },
    {
    "StopCharge": [
    {
    "ID": "QByteArray"
    }
    ]
    },
    {
    "SetCharge": [
    {
    "Level": "ushort"
    }
    ]
    },
    "GetStatus",
    "GetInfo"
    ]
    },
    {
    "Identify": [
    {
    "get": [
    "IdentifyTime"
    ]
    },
    "status",
    {
    "Identify": [
    {
    "IdentifyTime": "ushort"
    }
    ]
    },
    "IdentifyQuery"
    ]
    },
    {
    "OnOff": [
    {
    "get": [
    "state"
    ]
    },
    "status",
    "Off",
    "On",
    "Toggle"
    ]
    },
    {
    "LevelControl": [
    {
    "get": [
    "CurrentLevel",
    "RemainingTime",
    "OnOffTransitionTime",
    "OnLevel"
    ]
    },
    "status",
    {
    "MoveToLevel": [
    {
    "TransitionTime": "ushort"
    },
    {
    "Level": "uchar"
    }
    ]
    },
    {
    "Move": [
    {
    "Rate": "uchar"
    },
    {
    "Mode": "uchar"
    }
    ]
    },
    {
    "Step": [
    {
    "Mode": "uchar"
    },
    {
    "Size": "uchar"
    },
    {
    "TransitionTime": "ushort"
    }
    ]
    },
    "Stop",
    {
    "MoveToLevelWOnOff": [
    {
    "TransitionTime": "ushort"
    },
    {
    "Level": "uchar"
    }
    ]
    },
    {
    "MoveWOnOf": [
    {
    "Rate": "uchar"
    },
    {
    "Mode": "uchar"
    }
    ]
    },
    {
    "StepWOnOf": [
    {
    "Mode": "uchar"
    },
    {
    "Size": "uchar"
    },
    {
    "TransitionTime": "ushort"
    }
    ]
    },
    "StopWOnOf"
    ]
    },
    {
    "Basic": [
    {
    "get": [
    "ZCLVersion",
    "ApplicationVersion",
    "StackVersion",
    "HWVersion",
    "ManufacturerName",
    "ModelID",
    "DateCode",
    "PowerSource",
    "LocationDescription",
    "PhysicalEnviroment",
    "DeviceEnabled",
    "AlarmMask",
    "DisableLocalConfig"
    ]
    },
    "status",
    "ResetToFactoryDefaults"
    ]
    },
    {
    "EVSE": [
    {
    "get": [
    "ChargerStatus",
    "ChargerFault",
    "ChargeLevel",
    "SessionId",
    "SessionTime",
    "SessionSummationDelivered"
    ]
    },
    "status",
    {
    "StartCharge": [
    {
    "ID": "QByteArray"
    }
    ]
    },
    {
    "StopCharge": [
    {
    "ID": "QByteArray"
    }
    ]
    },
    {
    "SetCharge": [
    {
    "Level": "ushort"
    }
    ]
    },
    "GetStatus",
    "GetInfo"
    ]
    }
    ],
    "id": "comp1"
    }
    ],
    "id": 16022,
    "image": "default.png",
    "model": "LZL4BWHL01 Remote",
    "name": "LZL4BWHL01 Remote"
    }

    As you can (hopefully) see, I am simply trying to detect when the “On” button is pushed on the remote and turn on two lights. However, when I set the var “active” to true for the action, I get the following showing up in the log file:

    Mar 18 11:02:25 cush ZBPServer[15767]: Incoming connection.
    Mar 18 11:02:25 cush ZBPServer[15767]: Scheduler:: socket added
    Mar 18 11:02:25 cush ZBPServer[15767]: http_parser:: PUT /actions/17694
    Mar 18 11:02:25 cush ZBPServer[15767]: http_parser:: body: {“active”:true}
    Mar 18 11:02:25 cush ZBPServer[15767]: Scheduler:: socket removed
    Mar 18 11:02:26 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:26 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:26 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:27 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:27 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:28 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:28 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:28 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:29 cush ZBPServer[15767]: DeviceConditionHelper::evalCond: Attribute not found in dev cache
    Mar 18 11:02:29 cush ZBPServer[15767]: Incoming connection.
    Mar 18 11:02:29 cush ZBPServer[15767]: Scheduler:: socket added
    Mar 18 11:02:29 cush ZBPServer[15767]: http_parser:: PUT /actions/17694
    Mar 18 11:02:29 cush ZBPServer[15767]: http_parser:: body: {“active”:false}
    Mar 18 11:02:29 cush ZBPServer[15767]: Scheduler:: socket removed

    Do you know of a good (preferably online) resource for my understanding and correctly parsing the JSON to come up with the correct “path” to use in my action condition?

    Thanks,
    😀

    Anonymous
    Post count: 19

    Brief update on this, if I change the path to have “devices” instead of “device” (add the “s) with the following command:

    curl -H "Content-Type: application/json" -X PUT -d '{"path":"devices/16022/OnOff/state"}' http://cush:50334/actions/17694/conditions/57401

    Then the error in the log changes to:

    cush ZBPServer[3477]: DeviceConditionHelper::evalCond:: context does not have enough values. len:4

    Regards,
    😀

    Anonymous
    Post count: 259

    Sorry i took a while to respond, I was trying to test this scenario in the lab.

    “path”: “device/16022/comp1/OnOff/get/state”

    The path should be:

    "path": "device/16022/comp1/OnOff/On"

    [or Off or Toggle]

    I have some bad news: it looks like the version you have does not Evaluate Commands received in the Conditions (REST and XML API). This means that even if you setup a Condition properly and receive the correct command from the device, the ZBPServer does not pass that to the Actions-Manager.

    We have added support for the remote in the App. Just need to test functionality with scenes and then we can release it.
    Also we will let you know when the new zbpserver release with command support in conditions is available.

    Let me know if you need help with anything else.

    Anonymous
    Post count: 19

    Sorry i took a while to respond, I was trying to test this scenario in the lab

    No problem at all – you’ve actually been very responsive and helpful from my perspective.

    I have some bad news: it looks like the version you have does not Evaluate Commands received in the Conditions (REST and XML API).

    Well that explains why no matter what I put in the path, it didn’t work. Thank you.

    I look forward to getting both the updates for the app, as well as the new zbpserver. Is there an announcements mailing list I can subscribe to for notifications like this? I see an “Announcements” section in the forum, but nothing there since 2011, so not very active. 🙂

    Take care,
    😀

    Anonymous
    Post count: 259

    Thanks for understanding,

    Yes will add you to the announcements list. We will also have a subscribe on our website soon.

    Anonymous
    Post count: 19

    Hi Dhawal and team,

    Just checking on on this thread – do you have an anticipated date when the new iSmartenit app version with support for this remote will be released?

    Also, any ETA on when the new zbpserver release with command support in conditions will be available? As you can see from my other thread, I seem to keep adding devices that aren’t specifically supported yet, and would like to be able to use the API to add support for them.

    Thanks!
    😀

    Anonymous
    Post count: 259

    The latest release of App is in testing phase, once cleared we will publish it and let you know. Should be done by next week.

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.