Hi,
We just released the pre-ALPHA pdf for the Ezlo LUA API. We’re waiting for your feedback in the comments over there. 
Ioana
1 Like
Thank you @Ioana, I was reading through it. I honestly have drafted a survey to the developers asking them if they preferred to maintain the old API/luup syntax or if it had too many problems and would want to start fresh but then recanted… I thought the answer would be obvious from the community but I will just give you my personal input and honest impressions.
We have a reasonably large and active community here. However you can see from the list of members than many (most) of the developers of old times and most active members have left.
To me what worked on the vera were:
- The local GUI device representation
- Lua/plugin both flexible and powerful
- Community forum
- The initial ability to run completely local
What did not work are:
- The zwave stack and command queue
- The engine reload at every sauce. And to a lower extent, device reboot abuse.
- Excessive desire to automate configuration and network management
- The incorrect use of the hardware resources. (I have storage in mind)
- The lacking zigbee stack support.
So my point is… It seems to me that you are very focused on changing what already worked. Yet leaving alone what was deficient, some which are foundational.
- The local GUI device representation: Gone to cloud and mobile.(for now)
- Lua/plugin both flexible and powerful: Radically changed
- Community forum: Increased censorship without courtesy notifications.
- The initial ability to run completely local: This has degraded over time with increasing dependance to the cloud and now is where you started your development from.
For what did not work and could use some changes:
- The zwave stack and command queue: No idea where this is going and I am scared to death that you will be using the same old stack handling and command queue. The inability to fix this after all these years does not give me a lot of confidence. The absurdity of some of the designs is still leaving me in awe.
- The engine reload at every sauce. And to a lower extent, device reboot abuse: This seems to be much better from what I have seen with the new data structure of the firmware.
- Excessive desire to automate configuration and network management: TBD
- The incorrect use of the hardware resources. (I have flash storage in mind): TBD
- The lacking zigbee stack support: TBD
It would really be helpful if you had designed an device level API and Lua API to be compatible or near compatible with the old one. At least for now so you can evolve it over time and benefit from all the integrations and plugins already written with maybe only minor changes.
You will understand from this long post that it all makes the decision to stay a little difficult. I am glad to see progress and this all has a lot of potential if I was starting from scratch… but we are not.
3 Likes
Hello @rafale77,
Thank you for your feedback.
Luup engine has monolithic architecture. It’s difficult to take only positive functionality and don’t take related problem with that.
Part of described issues are already fixed and another part in our roadmap.
I am scared to death that you will be using the same old stack
It’s completely new Z-Wave library.
Excessive desire to automate configuration and network management
Do you mean Lua API for working with controller settings?
The incorrect use of the hardware resources
Could you add details or examples of this issue?
The lacking zigbee stack support: TBD
It’s very important direction for us. But VeraEdge doesn’t have ZigBee module. Could you share list of ZigBee profiles which do you use? Or list of ZigBee devices which do you want to work with?
Sorry for hijacking this thread but @Sorin should have a pretty big list of Zigbee devices from the voted ”feature request - integrations” tag. Including Trådri, Xiaomi and Hue etc. Sharing is caring 
2 Likes
Thank you Andrey,
It is somewhat reassuring that you are using a new zwave library. How about the command queue?
“Do you mean Lua API for working with controller settings?”
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.
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:
runs circles around the vera. I actually made it run using the vera’s EM357 radio. (EZSP)
The incorrect use of hardware resource is pointing to an entire thread I started and is now deleted by the moderators here, discussing the storage partition of the veras… There is also the lack of usage of the multithread capability of the CPU…
1 Like
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.
For Zigbee
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.
2 Likes
Hi,
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:
{
"_id": "5e88a318f4947f07db6e7e13",
"batteryPowered": false,
"category": "switch",
"deviceTypeId": "600_3_4231",
"gatewayId": "5e6a7dacb7c77f07569bf50f",
"info": {
"manufacturer": "NEO Coolcam",
"model": "NAS-WR01Z"
},
"name": "SK Neo Power",
"parentDeviceId": "",
"reachable": true,
"ready": true,
"roomId": "",
"security": "no",
"status": "idle",
"subcategory": "interior_plugin",
"type": "switch.outlet"
},
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.
Cheers Rene
4 Likes
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.
2 Likes
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).
1 Like
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?
Hello @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)
2 Likes
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.
1 Like
Hi @andryist,
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).
Cheers Rene
2 Likes
You can put any new Lua plugin on your VeraEdge via SSH access. It was described in our documentation.
You can use Ezlo API Tool 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.
{
"method": "hub.items.list",
"id": "_ID_",
"params": {
"deviceIds": [
"deviceId0",
"deviceId1",
"..."
]
}
}
1 Like