![]() T19:21:04.286Z DRIVER added request handler for ReplaceFailedNode (0圆3). T19:21:04.286Z DRIVER added request handler for RemoveNodeFromNetwork (0x4b). T19:21:04.286Z DRIVER added request handler for AddNodeToNetwork (0x4a). T19:21:04.284Z DRIVER beginning interview. T19:21:03.298Z CONFIG Using external configuration dir /usr/src/app/store/.config-db T19:21:03.274Z DRIVER loading configuration. T19:21:03.274Z DRIVER unexpected response, discarding. T19:21:03.271Z DRIVER unexpected response, discarding. T19:21:03.268Z DRIVER unexpected response, discarding. T19:21:03.199Z DRIVER opening serial port /dev/zwave T19:19:59.772Z CNTRLR setting serial API timeouts: ack = 1000 ms, byte = 150 ms T19:19:59.772Z CNTRLR sdkVersion: metadata updated T19:19:59.770Z CNTRLR firmwareVersions: metadata updated T19:19:59.767Z CNTRLR productId: metadata updated T19:19:59.766Z CNTRLR productType: metadata updated T19:19:59.765Z CNTRLR manufacturerId: metadata updated T19:19:59.664Z CNTRLR received additional controller information: In the code snippet below, you see the driver restarting with the graphic letters, seemingly while the stick is mid-sentence, or because of ACK timeout. It seems like the stick just keeps talking like z-way was still listening? This ends up in the driver crashing repeatedly. Looking at the logs, I see a lot of Dropping message because the driver is not ready to handle it yet. It loads the whole network from the stick, but the driver keeps restarting? I threw up a docker for z-wave JS UI, and tried to connect it to the UZB stick. Mind you this is a big existing network, not a new controller stick. I’m still using openLuup as a secondary hub which mimics all the various devices using MQTT and the ALTHUE plug-in and logs all device and sensor data using the built-in Historian and viewed through Grafana.Īfter a long wait for an updated version of the rather crude and unfinished Z-Way integration to HASS, i'm now looking (reluctantly) in to replacing Z-Way with Z-wave JS. The same functionality is easily achieved within the Home app by appropriate shortcuts. The MiniMote buttons I had configured as scene triggers to do whatever I needed, most usually toggling lights. This gives, of course, both secure remote access and voice control. These are all brought together with a Homebridge installation running under Docker on Synology NAS with the Apple Home app as the UI. ![]() …however, they are, of course, Zigbee and not Zwave, but this doesn’t matter in my HA environment, which has now completely ditched Zwave and Vera for all lighting and control functions, and replaced them with Hue and Shelly devices. I should have realised this earlier, but with four buttons and approximately the same form factor, the Philips Hue remotes are viable replacements… Go get it if you need a very cheap, very reliable scene controller for your home.įinally, I’ve found an adequate replacement for my beloved MiniMote four-button remotes (I’ve had nine of them for the last 10 years or so!). The buttons support different actions (press, long press, double/triple press) and you can just call a service endpoint, or update a variable:į3e509c0-f2a7-4f40-a099-af765e87c9fe-image.png While I built my own Scene Controller Virtual Device and I’m using MQTT for other devices of the family, Shelly can call your HTTP endpoints on button presses and in this case is more than enough. It’s very small, so it will fit in your standard wall box easily. No relays, so it’s a scene controller with bonus point to the fact that you can use your own buttons and keep the aesthetics of your house. It supports REST API, MQTT and much more.ĭownloads Manuals App Guide User and Safety Guide Certificates & Declarations Declaration of conformity Declaration of conformity - DE What is Shel. Shelly i3 is an unbelievably cheap (9,99 EUR/USD) WiFi device that’s part of the fantastic Shelly family.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |