No I mean the inclusion process often failing because of excessive automation of the configuration. I hope this is not news to you. Also excessive intervention of the software in pro-actively changing data and user configurations. Deleting the virtual devices, child devices, automations even when they are orphaned… all well intentioned but should have a user input to decide whether or not to actually do them. The fact that they all rely on a reload of the engine to execute, which lead to an abuse of luup reload everywhere in the code. They should be independent functions manually triggered by the users. Not automated. User-data should be treated as sacred and never to be automatically modified.
Now I understand. We spend a lot of time now for correct migration user devices/items/rooms/scenes between updates. Z-Wave devices migration logic in Z-Wave plugin and can be fully replaced via custom plugin if you ready to write own Z-Wave integration plugin.
We try to avoid reloading firmware without a very good reason. Now We have one known issue with glib library which we use and we need to reload firmware after changing timezone on the controller. It will be fixed in next releases.
Thank you. It’s interesting project. But this library is not certified and has GPLv3 license.
On zigbee, I understand, it is an open source, non certified library. The purpose was to give you an idea of what could be done.
For Zigbee, I don’t recommend going after a device library but a full stack support as the base. I would really recommend supporting both the HA and the LL stacks with all endpoints. For reference, given the hardware firmware you use on the current plus and secure this library
Zigbee3 would be the best thing to add, and I say this as a zwave user. It opens up a ton of cheap bulbs and sensors. And, if the whole “CHIP” thing ever gets off the ground, there is an 80% chance it will be some variant of zigbee-over-wifi (more correctly called dotdot on wifi) so having Zigbee3 support would be half the way to chip support.
Hi - we’ve published an updated documentation for this API documentation.
We’re waiting for your feedback in the post.
Looking through the API i completely miss a way to get any true Z-Wave device level data. The UPNP definitions as used by Vera as something you could complain about, but it is a well defined standard and as far as i know widely in HA (https://openconnectivity.org/). Why reinvent the wheel? But more serious is that there is hardly any details to obtain about devices. Look at this wiki page http://wiki.micasaverde.com/index.php/Luup_UPnP_Variables_and_Actions and you see what I mean what we can see on a Vera.
This is all I see on the new platform:
"manufacturer": "NEO Coolcam",
"name": "SK Neo Power",
Much of this maps with the lack of core functionality of the new controller to make it a serious HA platform or even get it up to par with the Vera functionality.
You are spot on and, from my Linux FW testing experience, this will become an issue during the test/debug phase of the new Linux Firmware/HW . I reported a bug with a Zooz smart plug on an earlier Linux Firmware release and the development team requested additional z-wave device details. I asked if there was an API or some way to get the details (logs?) on the Linux Firmware but there wasn’t a way at that time. I actually had to exclude the device from the Edge running the Linux Firmware and include it on my Vera Plus running UI7 just to provide the relevant z-wave details so they could address a device-integration issue in the Linux Firmware. For this class of development bugs alone, they need to expose device details and I’m assuming that they just haven’t gotten to it yet. While we may not see it in a simple mobile App UI, it should be available via the more advanced WebUI and definitely via an API or logging to enable efficient development/test/debug.
You are 100% spot on.
We are in the process of exposing more and more of the functionality via APIs…
Could you help us by telling us which functionality is a priority so that we can start delivering those functionality in the APIs first? (every 2 weeks, which is our sprints, we hope to release new capabilities in the API).
Melih, back in February I noted that there was apparently no way for a plugin/device to watch a value on another device and receive an event when it changes in the Lua API. At that time, Andrey said they would add it. This is a pretty big miss in that API. Now done?
I’ll check this and you will get the status on that here @rigpapa
Implementation will be available in the next Linux firmware release( next thursday or friday ).
Here is draft of APICore Events - eZLO API.pdf (124.4 KB)
In this case its better to compare items and variables.
I don’t see anything that lists the command classes identified for a device. That seems important for plugins to be sure if they should interact with a given device.
Cloud API was designed as protocol independent API. We have a lot of nice Z-Wave features in our roadmap thanks to the community. We try to implement each feature in universal way and reuse data structures/API for other protocols. We are working on that.
Lua API provides full functionality of Z-Wave stack: list of commands classes, multi-channels, associations, etc. It’s not just variables as it was in old API. It’s specific Z-Wave data structures, events, functions. If developer knows Z-Wave well then it would be easy to use it. It’s very close to Z-Wave standard and specification.
You can create own plugin and create any item which will support any Z-Wave specific feature.
Z-Wave Lua API has published.
Maybe I will grasp the big picture at one point. Problem now is that we cannot yet used the Lua API, nor the local cloud API so it is al not visible. Looking at the Zwave API it does have much of what is needed indeed. Just not yet accessible and not seeing a way to link the zwave node ID back the de device ID strings in the cloud API. You may want to include the device type (zwave, zigbee, BLE,…) and its identifier in the match (Lua) API in the cloud API device details. At least gives a simple path down the API three. Also suggestion for the cloud API call hub.items.list, add a optional parameter to get the list for just one deviceId.
@Oleh, i looked at the items list and that are indeed the UI type variables and actions. It does not include the protocol level items, but I understand the plan is to hide that from the UI and only have those available for plugins. I would reconsider that as you will make life much harder for your support staff if the user is basically blind and cannot give more details than “it does not work” (killer phrase, ask your support team).
You can put any new Lua plugin on your VeraEdge via SSH access. It was described in our documentation.
You can use https://apitool.ezlo.com/auth for working with Cloud API now.
We are going to add nodeId to info section of device. Myabe not the next release, but soon.
We have already added it. It’s avaliable in the latest release.
What is the general device model outside of ZWave? If I’m writing a plugin that needs to track the state of binary switches and control them, for example, how do I get a list of all binary switches in the system, of whatever source? How do I control them without having to know that they are ZWave vs RS485 vs TCP vs HTTP vs Tuya cloud vs…some protocol I cannot possibly anticipate? How does a plugin insert itself into this model so that its custom binary switch devices become part of that fabric? How do we create a virtual binary switch that is tied to no physical device at all?
I looked, but the current documentation is not enough for me to start and I do not have time for hours of trial and error. Could be my skill level.
The local access described in the API is not yet working for me. Some key information seems missing, so I am waiting on the promised python examples to see what that is. The API tool is nice but how would you use that in code?
Thanks for the hub.items.list update.
It is very simple.
You need to use core.get_items from Lua API.
You will receive all items available in the system and just need to choose item you need with basic or switch in item name.
Core module is responsible for it and allows to add universal devices and items to hub model and plugin is responsible about behaviour of each item which was added
Core doesn’t know about protocols. It is providing external API for “universal” devices.
Plugin is descibing the bihaviour of each item.
Plugin is deciding how to control phisycal device included to the hub or make network request.
As written this is a bit concerning… when you refer to “item name” here, I hope that means you are not referring to a device name field over which the user has control and may change to something unusable in this context. Right? This “name” is not the name a user assigns to the device, it’s a system name (as in type), assigned, immutable, right?
Its a name which assigned by a plugin.
We have a list of names supported by system.
The list of these names provided in documention.