Pre-ALPHA Ezlo LUA API Documentation

Company Talks Official Announcements
#21

Well, that’s a pretty big omission. That needs to be provided in the first release. Absent that functionality, it’s not possible for any plugin/extension to respond in a timely way to changes in state of any device in the system. That means even a simple plugin like AutoVirtualThermostat wouldn’t be possible.

Have you guys made any effort to reconcile the current capabilities of the legacy Luup APIs with the new? I think that would be a useful audit.

3 Likes
#22

We will add it. This was not added just because our plugins do not use it but new firmware supports it.

We have Lua API for all Z-Wave stack what we use in our Z-Wave plugin. Any plugin can use it in parallel with our plugin. Yes, it will work only for Z-Wave devices but It’s possible to do. Also Z-Wave Lua API has more wide possibility than universal device/items model. If you know how Z-Wave works you can add a lot of extra functionality.

Yes, It’s very useful and we compare old and new capabilities all the time.
We added S2 support, multicast capabilities. We repeated old scenes functionality and continue to extend it. We provided full access to protocol specific API, used sandbox approaches for plugins. Yes, it’s not the same what Luup supports now but we are on the way to do the same and a bit more.

1 Like
#23

I’m pulling this out to let the concept sink in here. This statement actually confirms my worst fears about how this firmware is being built, and what was considered in the design and architecture.

This document should not have been a hastily-prepared reflection of what is currently implemented, but rather, a clear, detailed specification built many months ago, published at that time and reviewed by all stakeholders (including community, under NDA as needed), and used as a guideline to produce the implementation seen today. Shortcomings such as those I’ve pointed out could have been foreseen equally well and addressed then, months ago, before any code was written, and when any glaring shortfalls in the architecture or API itself could have been addressed; not now, when the concrete has started to set. The broken processes continue, and they continue to waste time (yours and ours).

Not your fault, Andrey; I’m not trying to shoot the messenger here. The problems here start well above your pay grade, I’m sure.

1 Like
#24

I share this concern. There are certain things which I was tempted to call out in to be in the realm of “captain obvious” which are being missed. Sorry this is a very american reference. Many things in the current firmware are obviously absurd and incomprehensible, granted, but building the firmware with at least looking at what the current capabilities are, what is important had has made for the success of the previous firmwares to build off of it seems such an obvious thing to do. It would be practically the first step in my design functional spec…

#25

We did say “firmware supports it”…it will be in the next version… :wink:
The statement is just about the fact that we are working on next releases and extending functionality of controllers with new great features which are very easy to use.

#26

@Ioana,

Thanks for the new Lua API. Let’s assume for now that complete incompatibility with existing plugins is not an issue. It is, but that’s another debate.

Although the new Lua API includes new Z-Wave functions not present in the old API, it is too high-level and does not allow access to Z-Wave functionality for many different types of devices. We need, at the very least:

  1. A method for sending arbitrary high level Z-Wave messages to a device on the Z-Wave network. The library should handle transport issues such as calculating checksums and handling S0 or S2 security.
  2. A method of sending low level Z-Wave controller commands, for example SET_RETURN_ROUTE before setting up a special association.
  3. An asynchronous callback mechanism for receiving responses from Z-Wave devices. For example, a xxx_GET message is generally responded to by a corresponding xxx_REPORT message, or else there should be a good method of handing timeouts.
  4. An asynchronous callback mechanism for receiving unsolicited messages from specific Z-Wave devices. Such a method should get the first access to the high level Z-Wave message (after decryption) before any other higher level parsing is performed.
  5. A registration method by which my plugin can be invoked whenever a new Z-Wave device with a given manufacturer-specific data is included.
#27

This functionality is hidden by transport level of our Zwave library.
Now we are providing application level in current version of API.

In the current API we have methods for supported command classes.
In current implementation - ROUTE is the part of Zwave chip functionaity.

Already have it. You can use it now.

Don’t have it now. But it is in our roadmap for future releases.

We have global include event for all Zwave devices and after this you are deciding what to do with this device in Lua logic.

#28

Is is possible to access the EZLO lua modules outside the execution context of a firmware plugin? For example, it would be handy if this worked for random experimentation…

# cat test.lua 
require "core"

local gateways = core.get_gateways()

if gateways then
   for _, gw in ipairs(gateways) do
     print("gateway: " .. gw.name)
   end
end

# lua ./test.lua 
lua: ./test.lua:1: module 'core' not found:
	no field package.preload['core']
	no file '/usr/local/share/lua/5.3/core.lua'
	no file '/usr/local/share/lua/5.3/core/init.lua'
	no file '/usr/local/lib/lua/5.3/core.lua'
	no file '/usr/local/lib/lua/5.3/core/init.lua'
	no file './core.lua'
	no file './core/init.lua'
	no file '/usr/local/lib/lua/5.3/core.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './core.so'
stack traceback:
	[C]: in function 'require'
	./test.lua:1: in main chunk
	[C]: in ?

Also, it would be awesome if a cross-platform simulator was available to facilitate plugin development and debug…

What do the ezlo developers use during development and debug of the device plugins beyond print statements?

2 Likes
#29

@Oleh, @Ioana - it would be helpful if someone could answer this development question…

1 Like
#30

Sure @blacey, one of our colleagues will reply shortly.

#31

Hi blacey.

It’s not available now

We have the tool we are using internaly and working on make it public.

#32

Does that mean that you are planning for this capability?

Fantastic! That will be very helpful to, and welcomed by, the developer community.