Creating my own device on EzloPi?

EzloPi
#1

I have several MHI split a/c units in my house that are currently not integrated with my Ezlo hub. There is a well-documented and maintained interface for ESP8266 to this a/c unit available on GitHub - absalom-muc/MHI-AC-Ctrl: Reads and writes data (e.g. power, mode, fan status etc.) from/to a Mitsubishi Heavy Industries (MHI) air conditioner (AC) via SPI controlled by MQTT, bridging the proprietary control of the a/c to MQTT.

This made me think of trying to integrate the a/c unit with EzloPi. Looking at the documentation and source code of EzloPi, it seems that each device is actually hardcoded in both the firmware and the Windows desktop application for configuration purposes.

What’s the envisioned way forward with EzloPi? Would I need to clone the git repository, develop the integration and create a pull request? And how do you keep track of the integrated devices if others start adding them?

#2

There are two different things here…

  1. EzloPi Board: this board will allow you to connect its GPIO to any other hardware (whether its another ESP board controlling some other a/c units or something else…EzloPi board will handle all the connectivity with cloud and so on and it will be seen in your ezlo account like a “controller”…

2)the board you need to control the a/c unit… you need to get the i/o for this unit to connect to the i/o of EzloPi board so that you can control this unit via EzloPi board using MeshBots.

#3

Hello @jouked.
We are currently working on integration of different interfaces with EzloPi project.
For now you can send the pull request and we will review it.
Write please if you have any questions with sources.

Thanks.

#4

You also can use our hub with mqtt plugin which is already available.

#5

It would work in this scenario as the available MHI-MQTT software (GitHub - rjdekker/MHI2MQTT: Arduino-based WiFi/MQTT controller for wireless operation of a Mitsubishi Heavy Industries air conditioner through its serial CNS port) happens to post unique values per topic. If there are json payloads on a topic, it’s impossible to control them trough meshbots.

Is the MQTT plugin still relying on an external (to the Ezlo Hub) MQTT broker or do you provider the broker as part of the plugin already?

BTW, to make better use of the MQTT functions, it would make sense to link MQTT to a virtual device instead of just to meshbots.

#6

Its a complete solution, you dont need anything else.

#7

Are you sure? After installing the MQTT plugin, there is no MQTT server running on the hub, and configuration of the plugin shows a screen which asks for a broker address.

I tried to install mosquitto locally on the hub using opkg, however the installed musl libc which is part of OpenWRT is too old to run the current mosquitto software.

Screenshot 2023-01-11 at 09.24.59
Screenshot 2023-01-11 at 09.24.59574×508 23.1 KB

#8

Hi @jouked , @Oleh I believe didn’t get the internal server part.
So you are right, MQTT plugin right now does not have an internal server. It is just a broker.
To make it usable by other plugins either we have to add mqtt capabilities to our FW API or make it a dependency library. These were not in our recent roadmap. But if you want to use mqtt as a library and you have the packages, we can assist installing those on your hub manually if it is possible. Let us know if you need assistance on that

#9

In MQTT terms, the server is the broker. The plugin you provide is a client. Anyway, for now I’ll get the hardware for the a/c setup and use an external MQTT broker to get things started.

I’ve setup a virtual device (a thermostat) and I’ll try to implement meshbots interacting through MQTT and copying the a/c behaviour into the virtual device. Let’s see if that works.

In the end, I feel the broker should be part of the plugin and plugin configuration. The Ezlo Hub’s proposition is to be the central hub of your smart home. A MQTT server should be part of that central hub.

Fo