Announcing Ezlo-Hub-Kit & EZ-Apps

Background and Overview (Why and What?)

During the transition from Vera to Ezlo, users will be faced with gaps due to missing capabilities and plugins that are not yet fully realized on Ezlo Hubs. I know this from personal experience because I am living it. The Ezlo team is busily building out their hardware, cloud platform and firmware offerings and will handily meet, exceed and surpass Vera’s capabilities in due time but today there are barrier-to-entry obstacles that will may make it difficult for users to seamlessly transition from Vera to Ezlo controllers. Examples include HomeKit, MQTT, Node-Red, House Modes triggering scenes, MyQ garage doors, etc.

@reneboer has done a bang-up job developing and supporting the bi-directional bridges Ezlo Bridge for Luup and Vera Bridge for Ezlo respectively and in that spirit, I am also developing a HomeKit bridge that leverages the Ezlo JSON RPC API to bridge HomeKit accessories to Ezlo devices.

More recently @rigpapa announced Reactor Multi System that orchestrates unified logic over federated hubs and devices (i.e. scenes triggered by a device on one hub triggers logic, akin to a scene, comprising independent devices spread across independent hubs). Reactor Multi System is similar in nature to Ezlo’s Meshene that will be native to Ezlo’s platform available later this year.

To develop the Ezlo HomeKit bridge, I wrapped many of the Ezlo’s lower-level JSON RPC API methods in higher-level Typescript, and Javascript, compatible APIs. With Patrick’s Reactor Multi-System announcement, it became clear that other developers could benefit from the off-hub API wrappers that I had already developed so I decided to repackage the API into an off-hub App SDK called Ezlo-Hub-Kit.

Specifically, Ezlo-Hub-Kit is a Node.js Package Manager module that provides a convenient, fully-typed, SDK for Ezlo Innovation’s automation hubs. The kit enables off-hub applications to discover local hubs, connect to them securely, retrieve properties such as devices and rooms, observe hub events and perform hub actions.

Examples & Demo EZ-Apps (How do I use it?)

As an example of the SDK simplicity and expressiveness, the following code snippet shows how to discover all Ezlo Hubs on the local network and log the ui_broadcast messages sent by each hub to the console.

// Discover hubs as they appear in mdns
discoverEzloHubs(new EzloCloudResolver(username, password), (hub) => {
    // Securely connect to the hub and register an observer of ui_broadcast messages that logs the message to console.
    hub.connect().then((hub) => {
        addObserver( UIBroadcastPredicate, (msg) => {
           console.log('%s %s:ui_broadcast %o\n', (new Date().toUTCString()), hub.identity, msg);

The snippet above, while only a few lines of code, actually does some heavy-lifting for an off-hub app. First, it starts an MDNS discovery process that calls a discovery handler every time an Ezlo hub is discovered on the local area network. The discoverEzloHubs discovery method is passed an EzloCloudResolver that retrieves the registered hubs’ credentials from the Ezlo Cloud and caches them for use until they expire (in this case, the same resolver instance provides the credentials for each discovered hub). Each time a hub is discovered, the discovery handler is called with an EzloHub instance that it uses to securely connect to the discovered hub and register an observer handler of ui_broadcast messages from that hub. From that point forward, every time the hub sends a ui_broadcast message, the observation handler is invoked with the message and it is logged to the console. In addition, Ezlo-Hub-Kit employs a keep-alive strategy to ensure that Ezlo-Hub-Kit enabled apps have a “working” connection as long as the hub is on-line and accessible. Here is sample output:

$ ./test/utils/hubMonitory.js --username blacey

Observing: 90000369, architecture: armv7l	, model: h2.1	, firmware:, uptime: 0d 11h 23m 28s
Observing: 90000330, architecture: armv7l	, model: h2.1	, firmware:, uptime: 0d 17h 57m 48s
Observing: 70060017, architecture: esp32	, model: ATOM32	, firmware: 0.8.528, uptime: 1d 17h 22m 38s
Observing: 70060095, architecture: esp32	, model: ATOM32	, firmware: 0.8.528, uptime: 0d 0h 0m 32s

Thu, 28 Jan 2021 18:33:51 GMT 70060095:ui_broadcast {
  id: 'ui_broadcast',
  msg_subclass: 'hub.item.updated',
  msg_id: 3262983542,
  result: {
    _id: 'DA79ACF7',
    deviceId: 'ZC5F00207',
    deviceName: 'Landscape 1-4',
    deviceCategory: 'dimmable_light',
    deviceSubcategory: 'dimmable_colored',
    serviceNotification: false,
    roomName: 'Exterior',
    userNotification: false,
    notifications: null,
    name: 'electric_meter_watt',
    valueType: 'power',
    value: 0,
    scale: 'watt',
    syncNotification: false

The hubMonitor is include with Ezlo-Hub-Kit.

Sample EZ-Apps

To further illustrate the simplicity of the Ezlo-Hub-Kit SDK, I have published a few EZ-Apps (Easy eZlo Apps) that address some of the current Vera-to-Ezlo transition pain points (I have been running these in my home for a while). In the spirit of Easy, each EZ-App is packaged as dockerized Node.JS app for Intel/AMD and ARM architectures - anyone with an RPI, Synology or other computer in their home with Docker installed can run these EZ-Apps in a few simple steps. While also performing useful functions, the EZ-Apps demonstrate how to discover hubs on the local area network, establish a secure web socket connection with each, register observers for Ezlo Hub events, change House Modes and control hub elements.

  1. EZ-HouseMode-Synchronizer

Easy HouseMode-Synchronizer propagates Vera House Mode Changes to all Ezlo hubs on the local area network. The EZ-App illustrates how to use Ezlo-Hub-Kit to discover hubs, change House Modes and how to wait for the hub to complete the mode change. Users who are transitioning from Vera to Ezlo may find this App useful because House Mode changes initiated on Vera will be propagated to every Ezlo Hub on the LAN.

  1. EZ-HouseMode-SceneRunner

Easy HouseMode-SceneRunner runs a scene on an Ezlo Hub immediately after it transitions to a new House Mode. The EZ-App illustrates how to use Ezlo-Hub-Kit to discover hubs, use observers to asynchronously act on House Mode changes and execute scenes. This EZ-App will appeal to Vera Users who have grown accustomed to employing scenes triggered by House Mode changes. As of this writing, Ezlo Hub scenes can not use House Mode changes as a trigger. EZ-HouseMode-SceneRunner bridges the this obvious gap until solutions like Ezlo’s Meshene and/or Reactor Multi System are available.

  1. EZ-MQTT-Relay

Easy MQTT-Relay publishes all ui_broadcast messages from Ezlo hubs discovered on the local area network to an MQTT broker. This EZ-App illustrates how to discover hubs, register observation handlers and publish to MQTT. This should appeal to Ezlo users who would like to push Ezlo controller/hub data to a time-series database (e.g. InfluxDB) for graphical reporting and analysis (e.g. Grafana).

Try out the apps - you will probably find them useful. The ReadMe included with each EZ-App provides the necessary installation and usage details.

Note: If you are a docker-compose user, the EZ-Apps repo contains a docker-compose.yml service definition file and unified configuration for the 3 sample EZ-Apps to make bootstrapping as easy as possible…

At this point, some of you may be asking, why aren’t these EZ-Apps Node-Red flows? They certainly could be if a Node-Red node suite existed for Ezlo hubs. However my objective is to demonstrate the simplicity of using Ezlo-Hub-Kit in hopes that it will inspire other developers to leverage Ezlo-Hub-Kit for additional applications like an Ezlo node-red node suite (any takers?)

Additional Information

The Ezlo-Hub-Kit ReadMe strives to cover the normative off-hub app usage patterns. Ezlo-Hub-Kit also includes a full suite of test cases that can serve as examples for using the API. And, its open-source, so there is always the code and comments within.

Contributors Welcome!

The Ezlo-Hub-Kit is open source to enable other developers to rapidly develop an off-hub app. I encourage other developers to leverage Ezlo-Hub-Kit for their own off-hub apps (e.g. Ezlo Node-Red node suite) to help flesh out and improve the kit (i.e. fork and submit pull requests). To facilitate contributions, I am documenting the steps required to contribute. I have also deployed a Continuous Integration workflow that will run developer’s pull requests against live Ezlo Hubs using GitHub Action Runners. You can see an example GitHub CI run here


Ezlo-Hub-Kit is the first Typescript/Javascript library that I have developed so I let the stones fly where appropriate (i.e. don’t be shy about constructive code critique or helpful idioms that will improve the overall quality of the code base for everyone). Furthermore, I am releasing v1.0.0-alpha.8 now to solicit developer feedback and, depending upon the feedback, may need to iterate on some of the API call signatures until 1.0 reaches beta status hence the alpha designation at this time.


I’d love to see an Ezlo node red suite. I currently use the Mios node in node red running on a Raspberry Pi, for monitoring some of my Z-Wave devices on my Vera hub for their status changes and use this with a Cast node for sending TTS announcements to Google Home speakers.

The Mios node can also be used with virtual switches in Vera that can then send commands to cloud services like Tuya Smart Life. So a Vera virtual switch device can then control a Tuya WiFi device etc.

I’ve never used Docker before may have to look into that.

I’ve used Renes Vera to Ezlo Bridge plugin, I currently have all my real Z-Wave devices on the Vera Plus mapped to corresponding virtual devices on the Ezlo Plus hub. Mainly did that so I have lots of devices on the Ezlo hub to test things.

And I am waiting for the Reactor multi system to be released to transfer my existing PLEG logic rules to it, in the hope that one day Reactor will work with an Ezlo hub.

So on Node-red you would just use the mqtt in node to subscribe to the topic

Never used MQTT either. I know that’s what the Home Assistant crowd use but don’t know much about it at all.

Exactly. Configure a Node-Red MQTT node to subscribe to the topic “Ezlo/#” and you will see all the messages in Node-Red. You can then split, etc. in your on the remainder of the topic.

For those of you who are using/planning to use Ezlo-Hub-Kit, I just published alpha release v1.0.0-alpha.10 to GitHub and NPMJS. It is predominantly an optional maintenance release because the previous alpha has been performing well in the EZ-Apps containers.

For anyone who is using Ezlo-Hub-Kit in an app, I highly recommend that you configure GitHub Dependabot to automatically detect Kit releases.

I have promoted Ezlo-Hub-Kit to beta quality and published the first Public Beta Release v1.0.0-beta.0 because I do not foresee any additional API changes at this time nor have any bugs surfaced.

$ npm search ezlo-hub-kit
NAME                      | DESCRIPTION          | AUTHOR          | DATE       | VERSION  | KEYWORDS                         
ezlo-hub-kit              | API for Ezlo…        | =bblacey        | 2021-03-02 | 1.0.0-b… | Ezlo Node Automation Zwave Zigbee

I expect the beta cycle to run about 2 weeks before I promote it to General Release v1.0.0.

You can get it from npm directly (easiest) or from the ezlo-hub-kit GitHub repo

To install is using npm, run the command npm install ezlo-hub-kit --save

Ezlo-Hub-Kit General Release v1.0.0 is now available.

$ npm search ezlo-hub-kit
NAME                      | DESCRIPTION          | AUTHOR          | DATE       | VERSION  | KEYWORDS                         
ezlo-hub-kit              | API for Ezlo…        | =bblacey        | 2021-03-20 | 1.0.0    | Ezlo Node Automation Zwave Zigbee

To install is using npm, run the command npm install ezlo-hub-kit --save

1 Like

Best Home Automation shopping experience. Shop at getvera!

© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules