You can now download the latest version of our softhub and CCTV +AI capabilities to run on both Linux and Windows.
Check it here :
We have had numerous bug fixes done and improved stability of the system.
The windows installer now is near a complete silent install which does check/install/configure everything needed for you.
Vidoo webUI now has integrated access to ezlogic, so you can directly access all capabilities of ezlogic web app, and create powerful automations for your devices in your softhub.
Coming soon :
A new look & feel for easy navigation and better experience
Vidoo nodes in ezlogic so that you can use video recognition triggers in automations
and more…
We are eagerly awaiting your feedback. Please test and let us know what works, what doesn’t work and what features you’d like to see added!
Is this software so you can create an Ezlo local controller with you own hardware? Say a RaspberryPi, or other single board computer, or a virtual slice in a server bank.
If so does it give you functionality parity to say an Ezlo Plus running the prevailing software?
Not to be overly negative but now you have Ezlo Plus controllers, Ezlo Pi mini controller (realy device hubs), Ezlogic.mios.com web page, and now roll your own hubs, Ezlo Softhub. That seems like many streams of concurrent software to manage.
Meanwhile I am waiting over one year for improved Z-Wave reliability and several months for enhancements to IP Templates.
Seems like doing a lot of parallel streams of work causes everything to be 70% done. Really think you would benefit from a more focused mission.
To that end when will there be a new Ezlo Plus firmware that reveals some of the Z-Wave improvements that were teased a few months back?
Yes the Softhub can run on your own hardware. Similar to Open Luup I guess, oh the irony…
You can run it on a Raspberry PI. When I tried it I had it running on a terminal only Linux Debian PC.
Softhub I believe is pretty much like a regular controller, obviously need to add Z-Wave and Zigbee USB sticks. Not sure if its fully like for like however.
EzloPI based on ESP32 boards are definitely not a fully featured controller like an Ezlo Plus. Many aspects of the Ezlogic web UI dont work with an EzloPi “controller”
Although they say support for things like variables and expressions and local Meshbot rules is coming.
Also no HTTP server API and they say they have the web sockets ws API but it was not working for me with MSR which uses that API for its connection.
EzloPi is quite a good idea however to be able to relatively easily build your own sensors for things not usually available as Z-Wave or Zigbee devices.
Although I was expecting an EzloPi sensor device to just appear as a new device on my existing Ezlo Plus controller. This is not the case, as the EzloPi’s do act like a “controller” in their own right. Which makes having sensors on multiple EzloPi “controllers” somewhat disjointed.
Side note the Ezlo Atom controllers were also ESP board based apparently.
I have been testing some EzloPi stuff lately and plan to do a series of posts in the forum about it at some point when they iron out some of the current issues.
I agree, some more focus is needed on the core functionality. Get the foundations right first and build out from there.
We are working on multiple things at once right But we haven’t forgotten any.
zwave stability fw is already in beta and it will be live shortly.
IP device template enhancements are also in beta and being tested. I will post another entry about those specifically.
I can clarify this hub topic as follows:
we have our single Linux FW. It runs on;
Ezlo Plus HW,
Ezlo Secure HW
Docker containers. (Softhub)
there are minor changes in docker due to the native of the platform. But we are improving there. So docker image does not contain some of the libraries and plugins we use. Eventually it will be same. Docker gives us the ability to run it where docker is supported like windows, linux, raspberry etc.
Additional to softhub, while installing it, you have the option to add a video recognition and cctv software. We have been working on this for some time and it was called Vidoo. We will refer to it as MiOS VideoAI. That is a complete different docker container but it is tightly integrated with the softhub installation it comes with.
VideoAI provides:
Integrate these triggers with meshbots so you can create automations with them. (now just runs on the softhub it is tied to. But it will support cloud meshbots shortly)
EzloPi however is based on our Atom FW. which is a lot more simplified version because the resources on atom hubs were very low and it was the intention.
So EzloPi fw will allow us to create smart devices which can run on low resource hw. we use ESP32 development boards now, and it will support more in the future.
Due to this constraint, the meshbot structure or the HTTP APIs need to be redesigned. we are working on Alpha versions now and we have some pretty good results with it.
Hope it helps on clarification.
Thanks for your interest and support.
I have experimented with the EzloPi software and agree it offers great promise. In fairness I haven’t tried the latest which I was told is much improved over the version I played with months ago. So maybe many of my concerns were resolved.
I do see this notion of EzloPi being a controller or peer to a EzloPlus as a liability. I feel there has to be a master/slave relationship with the controller and devices. I view EzloPi much like you do, a vehicle to create you own device. Something unusual and not likely to be commercialized by a large vendor. Currently you cannot include device status of an EzloPi in a local meshbot on a peer LAN to EzloPlus. You have to go cloud based. That is a serious limitation in my mind. This forum is littered with all the reasons meshbots should run local wherever possible.
This is why I wrote my own General purpose IO module in Arduino IDE running on ESP32 (A DIY General Purpose WiFi (IP) Based IO Module for Ezlo) . It is queried by HTTP GETS and I use the IP Template functionality of EzloPlus to manage that “slave” device. So this way I could have local meshbots control my custom IO Module. Unfortunately the IP Template area is another 70% done area in Ezlo. You can only interrogate certain sensor types and its missing a polling function so you can have background audits to sync state when local control changes the IP device’s state. ZWave handles this more elegantly with “Instant Status” functionality. I can live with Polling but the homerun is to design an “Instant Status” like API into the IP Template construct so local device state changes can be reported back to the controller on an unsolicited basis.
Anyway I realize finite resources to work on Ezlo functionality. I still stand by my longstanding argument that core functionality has to come first and be fully hardened and robust. When I see so much effort on new video logging, AI like image triggering, and so on I wonder if the latest feature pursuit comes at the expense of basic functionality hardening and completion.
Yes, this has changed but not in any way which (negatively) impacts you or really in any way you should notice besides more stable and faster releases of both.
What we are now doing is that the same (but newer and upgraded) softhub which you were using before now has additional capabilities (CCTV+AI) which is an optional add-on.
Regarding the Ezlo Pi “controllers” you can’t currently use Local Meshbot’s as we know and when I tried to use a Cloud Meshbot instead, there wasn’t the right trigger options in there that I wanted to use, so that was a no go also.
I then wondered if I could some how get the current value of my EzloPi sensor in to a variable that my Ezlo Plus could then see? But I wasn’t able to do that either.
So my sensor on the Ezlo Pi is currently pretty isolated and I cannot do much with it, in terms of creating a Meshbot rule that triggers when its current value goes Less than a certain number.
But we haven’t forgotten any.