EzloPi Product Development Examples

Hello everyone,
We created a guide on how to create an EzloPi AC Lamp setup with Relay interfacing.

NOTE: Before moving into this example it is very necessary to know about device registration,
provisioning, and converting the ESP32 device into an EzloPi device along with knowledge of
Ezlogic desktop app. All this information can collectively be found in an EzloPi User manual document.
General information and the users manual for EzloPi you can find in this thread: EzloPi - Introducing our brand new Open Source project - for ESP-based devices

1 Relay circuitry and lamp circuit setup.
For interfacing and controlling the lamp we will be needing following components:

  1. An AC lamp with lamp holder and wires to connect to AC mains.
  2. ESP32 device for converting it into EzloPi smart device
  3. An properly designed relay module
  4. Power source for ESP32 as well as a relay module
    The wiring diagram can be represented as follows:

In the same way connection of the components has been made as:

2 Interfacing a relay for an AC LAMP using Ezlogic Desktop app:
Note that before moving to add any device it should the new device added and should be able
to access from the mobile app.
image
Also, note that we will be adding the Relay under EzloPi serial 100004031.
Device addition will be started with the button Add device in the UI as above. From the dropdown
shown at 2 select LED at the moment since the LED option can be used for toggling the GPIO which
works for triggering the relay.
image
Select Output pin for LED, its 2 at the time. Pin 2 at output means RELAY is expected to be
connected at GPIO2 of ESP32 and the same pin will be controlled via mobile APP. The button can
either be enabled or disabled. Upon enabling the button user will have an extra control facility with a
button connected at GPIO5.
After a LED has been configured and pressed the Apply button we get this device added to the list.
image
After it, we write this GPIO configuration to the ESP32 (EzloPi) device connected to the PC with
pressing Set Config Button and after the update has been written we will get the success message
as
image
**Note: After configurations have been set to the device please reboot the ESP32 **
device
Now the relay has been added and it will automatically be updated in the device with the ID we
registered as following section 6 of the user manual titled “Interfacing a device” and can be
visible in the app as a LAMP as shown below on the device’s dashboard of the app.
image
Before that let us move forward knowing about the app.

3 Vera Mobile app
You can download the Vera android and iOS apps from the respective store by searching for Vera Mobile.
iOS App: ‎VeraMobile™ on the App Store
Android App: https://play.google.com/store/apps/details?id=com.vera.android
Install the app and open it.
image
Create a user account if you already do not have an account or log in if you are already a user.
image
The device added explained in section Error! Reference source not found. of user manual titled
“Registration of a new EzloPi device into Cloud and provisioning the device” will appear
after getting logged in to the app as below:


Tap into the device for entering into the device dashboard. You will see your dashboard as:

For checking the device that has been just added you can navigate to the devices list from the menu
as

The added device will appear as:
image
This is the device that has been added as instructed in section 2 of the user manual titled as
“Interfacing a device”.
We can control the device from this UI itself or we can also add it to the dashboard shortcut for
easy access and status.
For such, we can add the device into the dashboard shortcut as:

  1. Navigate to the setting in the top right corner of the app
  2. Press an edit button on the device widget
  3. A new dialogue will appear with all the interfaced devices. Currently, we have only one
    device in the name LED. Select the device checking the radio button on the left to the
    Lamp icon and press save. This will close the dialogue and you will see the lamp being
    added in the dashboard widget shortcut.
  4. After it, press “Done” as shown in 5 and now this process completes.

4 Controlling the lamp from the app:
Now we have completed all our setup and can control the lamp using the mobile app wherever we
are located at.
With the dashboard shortcut as mentioned in section 3, we can just press the icon for toggling the
state of the device. If the device status is off the Lamp turns OFF and if the device status is ON in
the dashboard icon the Lamp status will be ON in real-time.

Turning ON the lamp:
If you tap on the lamp icon as shown below, the icon changes with an indication of a glowing lamp and
so does the hardware lamp in real-time. In other words, power is connected to the lamp by triggering
the relay interfaced to the EzloPi hardware device.

Turning OFF the lamp:
If you tap on the lamp icon as shown below, the icon changes with an indication of a non-glowing lamp
and so does the hardware lamp in real time i.e. turns off or in other words power is disconnected
by triggering the relay interfaced to the EzloPi hardware device

4 Likes

I am going to give this a try. I have purchased a few ESP32 boards and ready to jump in. A couple of questions:

  1. I notice the system here assigns an ESP32 as a unique controller under the Vera app. Is it possible to host the ESP32 node as a device under an existing Ezlo Plus controller? I want to be able to use the Ezlo ESP32 as a device and not a new controller per se.
  2. If the EzloPi needs to be a unique controller can you write Meshbots from a different controller that can work on the inputs and outputs? Can a VeraPlus also control I/O on a stand alone EzloPi?
  3. If yes to #2, do you need WAN and cloud connectivity to control devices across colocated controllers or can they interact locally just on the LAN?

Hi @curiousB , we are so glad to have you on the topic !

1- The ESP32 is actually a controller on the backend but the device configuration you create on it will be a separate device on that controller. And,
We are working on unifying the connections to controllers on the mobile app so that you wont require to log on to specific controller anymore and will directly be connected to all of them at the same time (Ezlo controllers) And the devices screen will be populated by devices from all controllers . So you wont be even noticing that you are connecting to the Ezlopi board as a controller

2- Regarding meshbots, we currently have Cloud Meshbots where you can create Meshbots using any device from any controller. so your device on the EzloPi will also be included. Note that it works with Ezlo Controllers not Vera.
3- We also have in the roadmap to have a LAN version of the same ability. But it will take some time. So for now you can try Cloud Meshbots and let us know your feedback.

Just starting on this effort. I was able to erase and flash my ESP32 without any difficulties. Then was able to setup the WiFi without trouble. Connected. All good to this point.

When I get to the Login to Ezlo Cloud it just hangs there and the dialog box stays open. No confirmation of pass or fail and no traffic showing up on the trace screen on the lower part of the main app window. Further there are words on the Login dialog window Reset Password and Register that have no active buttons to them. Also Cancel is misspelled.

dialog EzloPi 2

Isn’t this just the same account I have for my Ezlo Plus controller and old VeraPlus controller? Or is the Ezlo Cloud yet another account I have to create?

I was able to play with configs some (add remove/device) but I am pretty limited until I get this registration going.

I might be doing something simple wrong any suggestions?

Hi @curiousB ,

Are you using the latest EzloPi version (v1.3.4)?
It looks like you have an outdated version. Could you please check Ezlopi Resources | Get Started with Desktop Windows Apps and let us know if the behavior replicates?

You should be able to log in using the same account.

We’ll be attentive.

OK. much more progress. Don’t know how I got such an old EzloPi app (0.0.1) but the one you suggested worked well.

So now I have erased and programed the device properly. Logged into Ezlo and registered and thereby created a new controller (numeric name). I was able to configure a relay (output) and a push on push off switch as an input tied to each other. Pressing switch toggles the relay state on/off/on…

So local control works suggesting the ESP32 is functioning properly.

The ezlogic.mios.com website shows the controller as online and the iOS app shows the controller active.

The new device called “Digital Out 1” shows as a child to the new controller on ezlogic.mios.com but I can’t control it from there. Weirder yet, in the iOS app it shows no devices under the controller in the devices area.

The online document says:

Use your Device

Now the device has been added and it will automatically be updated in the device with the ID we registered earlier and can be visible in the app as:

But I am not getting to auto population of the child device of the controller.

p.s. as a work around I created a cloud meshbot which simply activates, i.e. turns on the relay “Digital Out 1”. When I press the Run Once arrow in a meshbots listing the relay turns on. Oddly the Active switch beside the run arrow is greyed out.

p.p.s. created a relay off meshbot as well. I can turn relay on and off by using the run once command from ezlogic.mios.com. There is a bit of lag between execution and the relay changing state fastest was 3-4 seconds and a couple stretched to 10 or so seconds. Nonetheless it works reliably albeit some lag. Oddly new cloud meshbots don’t show up in the iOS client either. And as before the Digital Out 1 device does not show up in the iOS app device list.

Regardless I have majority of functionality working. Not sure if I missed a step to get device showing as a child under the controller. Odd it shows and operated from Ezlogic.mios.com but not from iOS app.

1 Like

EzloPi learnings:

  1. Using the EzlPi windows app to erase, flash, and configure the ESP32 went quite well once I had the latest app 1.3.4. All good.
  2. Getting the EzloPi logged into my account, WiFi setup, and have the system generate a controller number went equally well.
  3. For some reason I could not see the (any) child device under my EzloPi controller in the iOS Vera app. The controller showed up, and I was able to log into the controller but the device area was blank.
  4. The ezlogic.mios.com site showed listed the EzloPi controller and under the devices tab it showed the child device “Digital Out 1”. This web page doesn’t let you control the devices, only see them listed (not an EzloPi thing, same goes for my EzloPlus ZWave devices). So it was confusing the child device shows up in one place but not another.
  5. I was able to create a pair of cloud based meshbots triggered by a virtual switch on my EzloPlus controller. This was my work around for not having the device show up on the iOS app. I could turn on and off the relay/led off of EzloPi by running the meshbot manually (run once) from the ezlogic.mios.com website or by toggling the virtual switch on my EzloPlus controller via the iOS app. Turn on and off of the relay wasn’t reliable though. It would work for a bit then not at all and then work later. I was thinking this was WiFi being less robust than ZWave.
  6. To prove my WiFi vs ZWave hypothesis I added a second action to each of the meshbots to turn on and off a ZWave lamp. I just assumed the ZWave would work everytime and the WiFi EzloPi would stay intermittent. I was wrong. They both were intermittent. I went into the iOS app and controlled the ZWave device directly and it turned on and off dozens of times never missing a beat. So the ZWave link from EzloPlus controller to the ZWave switch was reliable. So why is the controlling of the WiFi device and ZWave device unreliable?
  7. I think the problem is emerging as the cloud based meshbots are not reliable. As I have noticed before with ZWave devices at the fringe of RF coverage sometimes ZWave performance is unreliable. I have speculated the lack of a closed loop confirmation for each device state change (or at least an audit loop that runs in the background to compare app status/state versus device status/state), then the system is seriously hampered. You need 99.98% certainty a device is properly reflected in the app as to the state it is in. An “attempt” to change state isn’t good enough, you need confirmation. As Yedi says: Do, or do not. There is no try.
  8. I’d like to test the EzloPi relay from the device page of the iOS app to see if it switches on and off as reliably as the ZWave device does off of the EzloPlus controller. I need some help to get the EzloPi to show child devices in the iOS App. Help please.
  9. I was going to try a few types of devices off of the EzloPi but without the direct visibility of the device in the iOS app it seems too difficult for now. Same issue as #8. Help please.
  10. It would be nice if the system supported DS18B20 digital temperature devices. I notice it already supports DHT11 and DHT22. I would think adding the very common and inexpensive DS18B20 wouldn’t be a stretch and it comes in many styles including hermetically sealed units for weatherproof and liquid applications. There are plenty of libraries for this device in RPi and Arduino forums. The configuration should allow you to tell how many DS18B20s are connected as they share the one wire data-bus in an addressable manner. Some example libraries for the DS18B20 require you to enter the device address (unique to each sensor chip) but the better ones go out and poll the node and figures out who is there.
  11. The rest of the Add Devices options seem very good and quite thorough.
  12. I noticed in Cloud meshbots you cannot stagger the actions (when multiple actions for a single meshbot) with delays like you can in Controller based meshbots. Sometimes it is desired to set the sequencing of device actions through delays. Would like to see this added to cloud meshbots.

I do question the notion of setting EzloPi as a peer controller to gateway style devices like EzloPlus. It seems to me the use case for EzloPi is a slave, not a master. As such it would be just another device in an existing controller. By hosting it from a gateway controller then you could forgo the meshbot cloud interaction and make it work with meshbots running locally under the EzloPlus (or similar gateway) operating as the master. With all the concern of late with local vs networked based operation it would seem desirable to have as much functionality local and not WAN dependent. Given the issues I saw (item #7) I wouldn’t think you want to force everything to the cloud.

…

At this point I am kind of stuck until I get devices to show up on the iOS app. I do think there has been a lot of good work done here, but as anything, there is always a bit more to do.

1 Like

I will let others answer the remaining questions, but let me answer this one as its a “strategic” question.

The idea with EzloPi is to allow everyone from Device Manufacturers to Enthusiasts to be able to create devices that will work with our without a hub.
So, when lets say a user buys their very first home automation device (whether this is Door/Window sensor based on EzloPi, or thermostat based on EzloPi), they should be able to simply use it. The way we have done it, you will still be able to control it locally (mobile app will control it locally etc)…and in the future, depending on the configuration we can even run some basic MeshBots locally in the device… hence it becomes hybrid controller and device all in one… (we already have done this with our Atom hub range using ESP) and we might bring this to EzloPi in the future.

OK I get the minimalist scenario you speak of. I guess if you add peer functionality as well then its moot as users can go either way. That covers both camps. By peer I mean a local EzloPlus gateway (such as an EzloPlus) can interact with all the EzloPi devices on the same LAN without going out to the WAN and cloud. You’ve seen some of the chatter here about autonomy of the gateway if WAN goes down. That scenes can be triggered by and/or have actions on any combination of Gateway hosted devices and EzloPi hosted devices on the same LAN. If that occurs then I am happy. Right now the only way to do that is with cloud meshbots so generally non operable without WAN/server connectivity. Given I am seeing less than a 50% success rate for Cloud based meshbot triggered by a state change in an EzloPlus virtual switch I am not too big of a supporter for everything in the cloud.

I’ll leave it to your data center guys to sort out the traffic burden that comes with each EzloPi demanding resources from your servers. Today you only have to manage the traffic/bandwidth/server resources for the gateways attached to your servers.

By way of example my VeraPlus network I has 93 unique devices running. Mostly ZWave but some IP Cameras and a couple other types. Imagine now if these were all unique EzloPi devices. Instead of dealing with the resources needed to manage a single gateway now you need to manage 93 “gateways”. I don’t know how chatty the traffic to the servers is on keep alive and other administrative traffic but it potentially grows massively. The traffic load on bandwidth and server resources will increase massively. So hopefully such a large increase in offered load from millions of EzloPi devices is manageable.

our philosophy is that whatever can be done locally should be done locally (within good reasons).
EzloPi devices are designed to operate locally if you have a hub to work with.

we have some really cool ideas to create devices that are extremely efficient both in power consumption and architecturally as well as operate over Wifi…
We do not see the load as an issue.

Hi @curiousB
Genuinely appreciate for this detailed feedback.
iOS app has some problems that it does not show the child device configured with the desktop app and mobile team is working to fix it. You can use for now android application to have it working.
Thanks for recommendation on addition of DS18B20 driver, this was on the queue. We will be prioritizing for adding the driver to it in EzloPi firmware, it should be there very soon.
Please keep updated for new releases.

Hi @curiousB,

Let me summarize the points here:

1- IOS app should show devices. (Actually it should already be showing, since devices created on EzloPi firmware will be standard device category devices, so they would seem like any other relay, switch etc) Let us check this and get back as @Oleh said.
By the way, since this is a standard device, then you should also be able to control it over the dashboard on ezlogic.mios.com

2- Cloud meshbots should run properly. Let us also check on this.

3- Being able to control all devices in all controllers in a local meshbot
This is on our roadmap. We are working on it. It will get sometime since it is not a simple task to do, since we are not controlling other controllers from outside, where we can run code in a powerful computer, we are working on to do it on the hub itself. So it needs to be properly designed, tested and optimised. I will try to update the timeline on it as we progress.

Feel free to play more with it and tell us your feedback. It is much appreciated.

Mios Issues EzloPi.pdf (193.3 KB)

See attached. I have two EzloPi devices on my home network. Both show up on ezlogic.mios.com web site. They don’t show up at all on the iOS app. They are NOT controllable from the ezlogic.mios.com web page (or at least I can’t see how to). The relays tethered off of these EzloPis are controllable from cloud meshbots but they are quite intermittent which I think it is cloud meshbot intermittency rather than local LAN or EzloPi issues (only an educated guess based on intermittency of EzloPi vs. Zwave devises).

Looking forward to allowing local control of EzloPis from a colocated EzloPlus controller. I believe this will be essential functionality.

Update
p.s. I was able to get an Android device and loaded the Vera App. The Android app shows the device on the two EzloPis, Furthermore control of the relay is every bit as quick and reliable as controlling a ZWave device off of my EzloPlus controller. So this was a positive finding. So clearly some of the issues I had with the iOS app don’t exist on the android app.

On my second EzloPi I had configured a couple devices yet only the first one, the relay shows. I’ll go back and double check if I configured the EzloPi properly but suspect the system only sees the first device configured instead of all of the devices. More to come on this.

The fact I can control the EzloPi relays directly in a very reliable way does confirm the intermittency of Cloud meshbots. So there is something going on there that needs to be sorted. I presume that is an important matter for the viability of the cloud service aspect of the business.

Anyway progress continues.

Update2**

The Android app only sees the Relay 1 device despite 4 different devices configured in the EzloPi. not sure why the rest don’t show up.

Update 3*******
The local functionality of a push on push off switch on a relay configured EzloPi works well locally. Pressing the switch toggles the state of the relay. Good there. Even better is the EzloPi communicates back to the app to show the state change, essentially instantly. Those old ZWave folks here will know of the endless debates about instant status with ZWave due to Leviton’s patents (now since expired). So no worries that instant status isn’t supported with EzloPi.

As I said before in an EzloPi with multiple devices configured only the top relay device shows up on the app. So I went and reconfigured on of my EzloPis to remove the relay setup and replace it with a one wire and DT22 sensor (temp/humidity). The config worked and was properly saved in the ESP32. On the Vera Android app it shows no devices on the EzloPi controller?!?! So for some reason the temp sensor isn’t showing up as a device in the app.

Then I went back and added two relay configurations in position 2 and 3 on the EzloPi. Both the relays showed up and worked properly in the EzloPi but the temp/humidty sensor in device 1 is MIA. So you can have multiple relays but the one wire DT22 doesn’t work and doesn’t populate on the android app as a device.