HOME Forums Gateways Raspberry Pi Centralite Azela Relay Switch (3385001-RZHA) Issues

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • Anonymous
    Inactive
    Post count: 19

    Hi team,

    Not exactly sure what is wrong (if it is the iSmartenit app, or the Raspberry Pi gateway), but I suspect the gateway since the app appears to work fine, so I am posting it here.

    I have a number of the Centralite Azela dimmer switches (3385001-ZHA) installed in my home and they work well. I also noticed that the Azela Relay Switch (3385001-RZHA) is actually on the compatibility list for the iSmarenit app, unlike many of the devices I’ve tried to add lately, so I wasn’t expecting any issues when I connected it. And sure enough, it discovered fine, was recognized by the app and started working. However, after a few minutes I noticed that the switch would no longer turn the load on and off when I manually pressed the switch. The iSmartenit app continues to work fine, but manually pressing the switch doesn’t work.

    Hmmm. I then edited the device in the iSmartenit app and Removed it from the network. Presto! The manual switch worked again. I did a reset to factory on the switch and indeed it connected back to the network again, and within a few minutes the manual switch stopped working again. I removed it from the network and again it started to function.

    Not sure exactly how to troubleshoot this and could use your assistance. I’m sure you already have a capabilities list for this device, but here it is just in case it will help:

    {
    "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"
    ]
    }
    ],
    "id": "comp1"
    }
    ],
    "id": 50096,
    "image": "default.png",
    "model": "Relay Switch",
    "name": "Relay Switch"
    }

    I thought it was perhaps simply that one device malfunctioning, so I installed another identical device. Sure enough, the same thing happened with the second device as well. Functions fine for a while, then the manual switch stops functioning. I can continue using the iSmartenit app just fine to turn the load on and off, even when the manual switch is not working. When I was adding the device again (to capture data for this post), I captured the following logs. Sorry, there is a lot of noise in this log as well – as you can tell I’m getting quite a few devices on my zigbee network. 🙂 That first device join in the logs may not be the relay switch – I have a couple of “phantom” devices that tend to join occasionally which I still haven’t tracked down yet…



    Thanks for any help,
    😀

    Anonymous
    Inactive
    Post count: 259

    Our ZBPServer software automatically does the binding and configures reporting for the ZigBee OnOff Cluster. I suspect that the Centralite firmware has issues with this binding. Can you please send me the log file: /var/log/zbp.log

    Can you please try disabling the reporting? Here’s the code for that:

    PUT http://{{ip}}:{{port}}/devices/{{ID}}/comp1/OnOff/config
    {
    "attributes": {
    "state": {
    "report": {
    "enabled": false,
    "type": "change"
    }
    }
    }
    }

    Tip: You can monitor the log file with the command

    ztail -f
    Anonymous
    Inactive
    Post count: 19

    Can you please send me the log file: /var/log/zbp.log

    Sent via email. Also tried to disable reporting via command below, no joy. (details in email).

    Regards,
    😀

    Anonymous
    Inactive
    Post count: 259

    Emailed reply for community reference:

    Hi Darren,

    The Configure report request needs to be a PUT not a POST.

    I think when we add the Zigbee Bindings for configure reporting the Centralite devices have a behavior that I do not understand (unable to control relay locally). So to solve the problem we will have to delete the bindings. Currently the REST API does not allow management of Zigbee device bindings, but I think disabling the report could solve the problem. But if not then we will allow for deleting of the bindings through the current App.

    I will try and upload a new model reference to enable the binding management through the App, and will let you know when that is available.

    Thanks for your patience.

    Anonymous
    Inactive
    Post count: 19

    The Configure report request needs to be a PUT not a POST.

    In the immortal words of Homer Simpson – “DOH!” 😳

    So I changed it to a PUT. The response from the server changed to “200 OK” and gave a message back of:

    { “message” : “Device configuration updated”, “success” : true }

    I also see in /var/log/zbp/zbp.log that a zigbee packet is sent to the device and data received back that the reporting is indeed turned off:

    May  2 20:47:02 cush ZBPServer[17797]: Incoming connection.
    May 2 20:47:02 cush ZBPServer[17797]: Scheduler:: socket added
    May 2 20:47:02 cush ZBPServer[17797]: http_parser:: PUT /devices/50096/comp1/OnOff/config
    May 2 20:47:02 cush ZBPServer[17797]: http_parser:: body: { "attributes": { "state": { "report": { "enabled": false, "type": "change" } } } }
    May 2 20:47:02 cush ZBPServer[17797]: ZBP_packet:: [TX] (00) Cmd: 0030 len: 10 data: 02 00 30 10 82 6a 5b 01 00 06 06 01 00 00 00 10 ff ff ff ff 83
    May 2 20:47:02 cush ZBPServer[17797]: Scheduler:: socket removed
    May 2 20:47:03 cush ZBPServer[17797]: ZBP_packet:: [RX] (00) Cmd: 1031 len: 08 data: 82 6a 5b 01 00 06 07 00 CRC: 9a
    May 2 20:47:03 cush ZBPServer[17797]: OnOff:: Report configuration rsp received
    May 2 20:47:03 cush ZBPServer[17797]: OnOff:: repconf rsp received for attr 'state' (0): status: 0x00

    And … when I press the switch manually … drum roll … the light still doesn’t come on. 😥

    Will wait patiently for the updated App. Seems there are a lot of updates coming for that App… 🙂

    Take care,
    😀

    Anonymous
    Inactive
    Post count: 19

    Gentlemen,

    It’s been a couple of months, any sign of that updated app? 🙂 I have a number of these Azela Relay Switches around the house now, but they are not tied in to the zigbee system since when I do they can’t manually control the lights.

    Also still waiting for the update to ZBPServer on the Rasberry Pi so I can use the deeper functionality of the API…

    Any updates?

    Thanks,
    😀

    Anonymous
    Inactive
    Post count: 259

    Hi there sorry for the delay, we should have some good news by the end of next week, let you know soon, thanks for your patience.

    Anonymous
    Inactive
    Post count: 259

    Hey there, finally able to update the reference for the Azela relay problem. So here’s what we need to do:

    The symptom that you explained with the Azela relay is I suspect, due to binding that we write in the device. So the solution is to remove that binding. We will try to remove the binding through our iSmartenit App.

    The reference file has been updated, so please open the iSmartenit App with internet connectivity so that it updates the latest reference successfully.
    Follow steps below:
    1. Open the iSmartenit App
    2. Connect to the Gateway
    3. Go to the Azela relay device settings view (Locate the device and click on it to navigate to the view where you can change the name and picture).
    4. Top right is a pencil icon, click on that and then you should see Manage Links, click on manage links.
    5. You will see all the Links (bindings). Delete the one with Relay and Save.
    6. Go back to Manage Links and confirm if link has been deleted successfully.

    Check if the local relay is working. Let me know how it goes. Thanks a lot for your patience!

    Anonymous
    Inactive
    Post count: 19

    Hi Dhawal,

    Sorry, I was gone all last week for a business conference and just got back recently. I followed your steps exactly and indeed, now the local relay is now working with the relay still connected via zigbee to the gateway.

    Some questions:
    – What will all the effects of deleting the binding be? For example, will deleting this binding mean the relay CANNOT be used in scenes and wizards?
    – will this setting update itself again at some future time and I’ll need to keep deleting it? I’ve noticed that with the Smartenit App that happens – items which were deleted mysteriously reappear again from time to time.

    Thanks for your help,
    😀

    Anonymous
    Inactive
    Post count: 259

    now the local relay is now working with the relay still connected via zigbee to the gateway.

    Glad to hear that!

    – Some questions:
    What will all the effects of deleting the binding be? For example, will deleting this binding mean the relay CANNOT be used in scenes and wizards?

    The effect of deleting this binding means that the device may not report on change to the Gateway, please check and let me know.
    You will still be able to use it in scenes and Wizards(effects, maybe in conditions if you see report on change of relay is working).

    – will this setting update itself again at some future time and I’ll need to keep deleting it? I’ve noticed that with the Smartenit App that happens – items which were deleted mysteriously reappear again from time to time.

    This binding is added by the zbpserver when the device joins the network, so if you remove the device from network and join it again, then you will have to delete the binding again, otherwise it’s good.

    Thanks for your help,

    Thank you for your patience 🙂

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