Great. Looking forward to submit my application.
I think there are so many requests you collected during the first phase. Do you have a list of thing you wish to target with this new release? Zigbee, Bluetooth?
Regards
Will PLEG be supported or be incorporated into any new hardware/firmware?
How about ALT UI?
How about DataYours?
What is the “roadmap” that people are referring to?
i will try to support ALTUI but that depends on availability of an API / documentation and having beta program access
2 Likes
Ditto with my apps including DataYours.
2 Likes
Don’t know about PLEG, but like @amg0, I’ll make Reactor and all of my other plugins work anywhere that I have sufficient access to developer tools and support. Actually, I’m really excited to do this, as many great suggestions have been made for improving the APIs that could really help us take things to the next level.
4 Likes
Hi,
They said (for now?) no support for third party plugins, so we as plugin developers can keep our focus on the existing platforms. No point in spending time on the Atom. Read the current specs here Beta Test Our New Ezlo Atom - Official Announcements - Ezlo Community
Cheers Rene
We think that developers, even without the support for plugins at the moment, are the best critical eye we can get for a new product, giving their technical understanding of the underlying of a device or service.
Keep in mind that you get to keep the product and be first to test new features as they come.
Hi Sorin,
True, but i mean for updating our current plugins as the above articles are referring to. And many developers are not in the US, so cannot be in the Beta either.
Cheers Rene
From the announcement:
Just pointing out, our plugins don’t seem to be an issue for this Beta, at least, not in a way that would seem to make any work for us. @Sorin, have I read this correctly?
1 Like
Do you have plugin support ? Add me as a Beta User candidate.
I will provide Vera Alert and Program Logic capability.
These are two very popular Plugins on Vera.
If the base system has enough functionality … these may not be needed … but I will be able to decide and advise existing users based on results of the Beta evaluation.
3 Likes
Richard, the Atom does not have plugin support just yet but we’d love to have you on board anyway. I’ll send you a private message.
I d like to try, but I am in EMEA. do you have beta for EMEA support sometime ?
Linux Based version will run on the current hardware our users have.
Plugin support is being coded as we speak. I don’t have an exact date, but hoping to deliver it by the year end (don’t hold me to it as its just a guesstimate).
Any “new” Vera is useless to me without support for existing plugins!
I am beginning to wonder why the system is being “recoded” - it was not broken.
Perhaps you should provide a plan and direction document for those of us who are heavy Vera users.
If such a document exists - where is it?
It appears from many of the posts that some users are already planning to abandon Vera for other platforms.
I applaud their efforts to bring the system up to bleeding-edge/modern standards. Developers have dealt with a long litany of limitations; I’m not even talking about any bugs, I’m referring to basic architecture and implementation choices that may have made sense ten years ago, but don’t now. A deep, hard cut like this is brave, and if they pull it off, heroic.
As for the plugins, there are too many dead and unsupported plugins. If the new firmware has different interfaces or enforces new rules that require developer support to work on the new firmware, it will immediately separate wheat from chaff. The community can then focus clearly on addressing what may have been excluded that is still needed. But I’ve often said that the current app marketplace is a harrowing minefield of unsupported, non-working, and sometimes harmful offerings that do nothing to help new users get comfortable with the platform, and in fact, have quite the opposite effect. Time for those to go. Past time.
8 Likes
I would like to point out that the biggest problem I have run into with my Vera Plus installation is it not playing well with Zwave devices.
I am NOT AT ALL interested in buying devices from the Vera Store. Not only do I dislike many of the designs everything on there is much more expensive than I can get on the open market.
Right now I have 2 Zwave sensors from BeSense. One is a motion the other a door open/close. When armed both periodically at random intervals send tamper warnings even though they are not being tampered with. These are NOT sold in the Vera Store and the motion sensors that are are $15-$20 more expensive.
BeSense has no idea they claim they don’t see this with their testing on their Vera but they are obviously testing with older code.
Before anyone spews “if you want reliability buy from the vera store” I will point out that the ENTIRE POINT of open standards like Zwave is to allow things to play together. If you are a proponent of a “walled garden” in networking then I hope you remember that next time you can’t get your laptop to work in a coffeeshop and the shop says “only laptops bought off our website where we get a commission will work”
Vera seems little interested in testing devices and adding in “exceptions” to the Vera hub to make them work well unless they can sell these devices and make a commission.
I will also point out that what good is an automated home system if you cannot put sensors and actuators -everywhere- And that’s possible if the sensors are $10 or so but bank-breaking for $60 a pop sensors.
Microsoft Windows got where it is today because in the early days Microsoft went to the trouble of getting EVERY oddball piece of hardware and making sure it worked even when the manufacturer was long gone. CGA & HGC cards (through windows 3.0) and all sorts of old skankyfloppy controller tape drives and other nasty hardware was all tested and Windows modified to support. Vera needs to learn from this example.
We don’t need the kernel continually rewritten we need support expanded.
To your point of zwave being an open standard… I hope you see the paradox in your post… In order for the Besense sensors to misbehave on the vera… it is more than likely that they are not following the standard. I too have encountered some weirdness with various sensors at times but discovered now that they were not properly configured because these sensors needed to be setup with security classes and were not.
Besides these singular devices, I had the best luck with non officially supported devices on zwave. As a matter of fact, over half of my 143 zwave devices are not supported or were included and configured while they were not officially supported. Once the devices became supported, is when the mess came in as the vera tries too hard to run automated configurations which sometimes sets it up to go into infinite luup of device creation, luup reload, automated device deletion, luup reload, device creation…
So for your sensors… either they are not conforming to zwave standard stacks (some brands do it because they themselves have a controller which supports it) or your inclusion needs to be redone with security and this is something the vera struggles with for some devices because… as I discovered, it may be too slow in its inclusion process and the device too fast in its sequencing.
Besides these one or two exceptions, the vera has supported every device I threw at it. Albeit with some manual configuration at times.
1 Like
OK, so users are expected to be able to do manual configuration. Is this manual configuration process available on the wiki? I suppose a user might be able to look at a devices ‘Capabilities’ variable and determine how to configure it manually. If there’s information on how to do that I’d like to have a look at it.
It’s a good point… It is not well documented outside of this forum but a bunch of folks here have experimented and demonstrated how to do it. It generally comes down to only associate the right device type and device file to the created device and usually doing it using ALTUI to avoid the dreadful automated luup reload at every parameter edit.