Eternal problems of the Vera app

Our plan was to create a group with existing plugin developers (which we did in skype group), interact and learn and build together a good architecture for a plugin framework so that any plugin developer could benefit from it. We created that group and some plugin developers have been very helpful in helping us and some stopped communicating with us.
But with all the good work those plugin developers have been doing with our developers will result in an easy to use plugin framework that you can easily develop a plugin for.

Here is the step by step guide about how to create your own plugins with Ezlo API.
Together with sources for the examples. (4.2 KB) HowToCreateAPlugin.pdf (92.6 KB)

Hi @melih,
I must agree with Patrick, Skype is not a tool for communicating issues. Even with the few people on there too many conversations mix and I loose track of things. Mostly you team answers, sometimes not and I cannot blame them in between doing their jobs.

And one thing that I do not see improved, is QA. Too many issues make it to the published code just as we know all too well from the Vera updates. I reported plenty, but I am not keeping track if they get resolved.

Cheers Rene


This doesn’t exist today, it has yet to exist, and this is the problem. A framework results from planning and forethought. None of that applies here. You are fire-fighting, playing whack-a-mole, putting in things as they come up to fill a hole, with the hope that that someday becomes a cohesive “framework” (but, a bunch of functions is not necessarily an API, and an API is not a framework).

It’s not a plugin framework. It’s an accidental collection of functions that you’ve by chance been told are needed that may someday be complete enough but will still take much time to fully discover and implement. Good luck to you.



You recently reported an issue / request to the Ezlo development team with the LUA API in regard to the armed / disarmed status of security sensors.

Did you receive a ticket number?

How will you know if that issue has been logged at their end and not missed by them?

How will you know when the issue or request has been completed by them?

1 Like

I’ve been recommending a public-facing bug-tracking system since April (Ideas about how to Migrate Vera FW to Ezlo FW - #13 by LibraSun - General Discussions - Ezlo Community) but nothing has materialized.

Thus I must return to retest each and every previously reported issue to see if it got resolved with newer firmware/revisions, and then move on. Certainly makes the iterative process much, much slower than it would normally be.

A true bug tracker would allow users to be notified at each stage of acknowledgement, acceptance, deprecation, resolution, work-around, merger, rejection, etc. as well as provide direct feedback in situ for edge cases and troubleshooting purposes.

The best example of this setup in my experience was done by Yahoo! when they enlisted a bunch of us to help develop 2.0 of their Pipes product (now defunct). New features and known glitches were typically ironed out in hours or days, not weeks and months because of the powerful feedback loop afforded by their in-house bug tracker.


hi Rene,
you have been great in helping us Rene, much appreciate it. Great feedback.
Reality is no single tool is great for everything.
We need to do
3-Add hoc communication
and so on…
the initial skype group was setup for “Brainstorming” with a hope those discussions would then lead to further methods of communication. Bugtracking is a good idea for example.
So we need to setup all these different communication methods for their intended purposes.
So far I see:
-Skype for brainstorming/adhoc communication
-bug tracking system (public)
what other ideas please?


We’ve said it all before.

A public facing or login required bug tracking and feature requests system.

If we had this 6 months ago we would all be alot further forward by now.

I have reported more bugs than I can remember or likely can even find some of them again in the forum threads somewhere? and I’ve suggested many feature requests.

I have no idea if any of them are being tracked or resolved or if my feature requests have been taken in to consideration and moved on to the next stage of implementation?

1 Like

Everything coming in, bug or feature request gets recorded in our internal systems. We have been working on how to expose that. Gabriel is leading that initiative and he can chime in.

I don’t know how many bugs I have personally reported in the forums? At least 50 or probably more at a guess.

Who knows? I’ve forgotten and they have been buried in the forum threads.

Will it be read only? or will we be able to directly submit bugs into the system and provide additional feedback?

I would have to re-read all my posts in the forum, which there are many and try to find and list all the bugs I reported, probably a week to do that :thinking:and then compare my list to your list in the system.

Are forum users usernames noted in the bugs on your internal system? So you know who reported the bug?

1 Like

We are working on a public bug tracking solution and are aiming to provide an update next week, on what solution we will install.


Gabi OK this is good news and a step in the right direction, but it should of been done months ago.

Perhaps a bug tracking system such as this will help to retain some of the 3rd party Devs that have expressed their concerns and for those forum users who are beta testing and their enthusiasm may have waned due to lack of knowing if their feedback was really picked up or not?

1 Like

Six months ago? I brought up the non-existence of bug tracking 2 years ago in melih’s first days on the forums.

Which is sad because vera had a public bug tracker back in ui5

1 Like

6 months or 2 years what’s the difference.

It’s done now or wasn’t done as is the case.

what else do we need apart from bug tracking?
we have skype groups for plugin developers for brain storming sessions
we are putting bug tracking

what else do we need?

1 Like

Public feature request system?

Dedicated developer relations?

Public plugin architecture road map?

“Public” could be for registered developers but needs to be low bar to access.


Development roadmap would be great; what can we expect?

An app store for publishing and installing plugins.

Cheers Rene

1 Like

A robust, all-inclusive Wiki containing full documentation for each controller, device, feature, etc. I believe this has been done already, but if you held a gun to my head, I couldn’t tell you where to find it. (I suppose this page comes closest? Yet it doesn’t even link to the Forum!)

I think this, combined with the above suggestions, points to the overall impression of ezlo’s ecosystem being entirely too scattershot at present. It needs to be much more cohesive for newcomers to make any sense of things. (The Forum itself at least has decent structure, but for n00bs it still might look like deep, murky waters.)


Go sign up as a smartthings developer. See what they have.

Figure out what you need to do to lure developers away.

I picked SmartThings because they are not beloved by developers. I don’t know who is the best ecosystem for developers, but I am pretty sure it isn’t ST. Beating ST at developer support may be more than ezlo can manage, but it doesn’t set you up for crushing failure and has a possibility of some success.

With ST changing their language and api, they are going to disenfranchise a lot of their classic devs but also a lot of new devs will see an opportunity to get in on the ground floor of a large, hungry market.

If your environment is better, you may pick up some skilled devs. If not, you are going to be limited to people who wander into ezlo more or less by accident.

But never, ever forget that no matter how crappy their tools are or how many hoops developers have to hump through that part and parcel of “what they have” includes a global install base that’s probably two orders of magnitude bigger than vera’s ever was, copious agreements with other manufacturers, board-level involvement on multiple foundational technology special interest groups, direct product integration support from their appliance, home electronics, and smartphone divisions and indirect support from their heavy equipment and electronic fab divisions that help subsidize other Samsung ventures.


First of all thank you for all of your feedback and support.

As it was already pointed out, these items are not new and they’re standard tools provided provided by use in part with the old platform or provided by our competitors, so all of the items below are part of our roadmap and are today in different stages of our process.

Please see below more details per specific request:

  1. “Bug Tracking”
  2. “Public feature request system”
  3. “Dedicated developer relations”
  4. “A robust, all-inclusive Wiki containing full documentation for each controller, device, feature, etc.”

We are trying to solve for all of these requests with tools that are interlinked and are updated in real time based on out put from our internal tools. We analysed and tested several tools
and we are leaning towards Service Desk from the Atlassian suite. This will allow us to track different types of arequests as well as search through documentation or roadmaps posted in a Confluence workspace.
One of the small setbacks of using this tool is that the users will have access to their own tickets rather than seeing all tickets posted by all users. We’re working on solution for this.

  1. An app store for publishing and installing plugins.

I think it’s safe to say that the appstore we have for the old platform is severly outdated so the plan is to invest a lot of time in building a whole new app store with a lot of new features we’re missing today.
We will soon get started on this initiative and will be able to provide at leas a high level estimate of when this will be available.

  1. Public plugin architecture road map
  2. Development roadmap

We will include in the Confluence workspace a high level version of the roadmap, so users can check it before submitting a new feature request.