Making an ERV that plays nice with OpenHab? Practical?

Hey everyone! I was going to try to use Matter, but it looks like it’s not really clear it is really open. I am trying to produce an open source Energy Recovery Ventilator, and software is not my forte.

I frankly find the sheer variety and quantity of buzzwords and subsystems difficult to navigate.

I am using a raspberry pi pico running micropython. Do you think it would be practical to make it appear as a fan with several different modes to an openhab hub?

What I want is basically to allow it to be controlled by a hub, which may be running on a phone or someone’s PC, so the hub’s user interface etc. Can be used to make the device turn off an on, up and down on a schedule, it can be connected to other devices like a co2 detector, etc.

I need, sooner or later, possibly with the help of module(s) running on the pico to cache data, get the time or whatever, a dictionary which I will use for the rest of the system to interface to. The main loop consults the dictionary to determine behaviour at any given moment. The hub checks what time of day it is, etc. And sends that info along.

Is this sort of thing doable?

I tried to look into making the thing Alexa compatible and ye gads it would take me months to get that stuff working. They make everything so complicated.

Yes but it might be worth a quick perusal of the Concepts section of the docs so you are not led astray. From a practical perspective, OH has a relatively small set of primitives called Items which represent sensor readings and actuators. “Fan” isn’t really a concept that exists in OH at this level. A Switch indicating the ON/OFF status of the fan is though.

OH the server doesn’t run on a phone. But it’s UI is easily accessible from a phone. OH supports a “when event X occurs do Y” approach to defining behaviors. Several programming languages are supported (including Blockly if you’re not a programmer) so if you can think it, you can probably configure it (e.g. only turn on the fan when the C02 is > 600 ppm between the hours of 20:00 and 06:00 on weekdays).

OH supports saving data through “Persistence” and has built in charting.

Outside the scope of OH.

Rest of what system?

Wouldn’t it make more sense to have it be reactive? (e.g. send a message to turn on the fan, the fan turns on).

This really smells a little bit like an XY Problem. I think you need to spend a little more time thinking about boundaries and what sorts of things you want to have happen where.

As for communication between your device and OH, assuming it’s on the network you have a couple of choices. You can have your device authenticate to OH’s REST API and send data/poll for new data using that. Though were I to do this, I’d use MQTT which keeps your device independent from OH’s specific API and follows a pub/sub model which makes both OH and the device more responsive and reactive.

Once the device is represented in OH, you can use OH to expose it to Alexa. All the really complicated stuff is already done for you.

Hm, i will do some reading as you suggest, but it sounds like it would be alot of doing.

I think it would be a good idea to have reference designs or modules which can be used. The esphome for instance has this approach. You can use the configurator module to produce firmware for a wide variety of common devices like fans, switches etc. Their problem is that they went a little too far; the firmware spit out is a binary which you can’t use as a software module in a larger system.

So, they made it so you can easily get a little hardware nodule that takes care of things for you, then you can focus on the other hardware.

I need to be one step upstream. I need a micropython software module that takes care of things. Most of the stuff you mentioned doesnt really need to be exposed to the user, for instance. Not after module configuration, at least.

Weve been over this with wifi. For the longest time you had to enter the enceyption scheme etc. And a lot of stuff got done under the hood, but only relatively recently have the last bits of stufff finally been automated and stuffed under the hood. Now, even when I write a program in micropython, all i need is the ssid and password. 99 percent of the time there is no point exposing all the details to the user, not even a programmer.

I think the same applies here. Things are very complicated right now, but the way forward is clearly to optimize and smooth things out. Make it pythonic.

It sounds like essentially I would have to write my own micropython module. Since a general purpose one is more work, I would schlep it and make something that only works for me and is of little use to anyone else… alas.

Im talking about the dictionary as a sort of interface between modules. Its a demarcation line. On one side is one system, the other side is another. The erv has internal systems, there is wind compensation and all kinds of stuff, it is not just a power level and direction.

It’s worth mentioning here that openHAB isn’t Python.

It’s not micro python. It’s a platform upon which one can build a bespoke home automation system. It’s job is to bridge multiple disparate technologies (350+ at last count) and make it so they can work together.

I don’t know anything about micropython but MQTT is the lingua franca of the IoT/Home Automation world. Almost everything can talk MQTT including stuff like esphome, tasmota, and other ESP firmwares.

Typically, that would be some sort of messaging system or an API. And as I’ve mentioned, MQTT is usually the best choice for this because everything can use use it.

I wonder if you are use to working at a way lower level than something like OH operates at. If you decide to operate at the software modules level than yes, this is going to be a lot of work. But if you operate at the network messaging/API level it’s much easier.

I’m not sure I’m following you here. I have several ESP8266’s doing various jobs throughout my house. I can look at the code and modify it if needed. But I’ve never needed to. I wire up the sensors and relays to it, configure it through it’s web interface (e.g. these pins are connected to a relay, these to an DHT22, this analog one to a light resistant diode) and I configure it to publish the readings to specific MQTT topics and to subscribe to others for messages commanding it to flip a relay on or off. This becomes the microcontroller’s API. This is how the rest of your system interacts with the device.

Don’t want to use esphome? A quick search shows lots of tutorials and modules for getting micropython talking MQTT.

Then in OH I create an MQTT Thing which has Channels that are configured to subscribe and publish to those topics. These Channels are linked to Items and at that point, there is no difference between a Switch Item linked to one of these MQTT Channels to control a relay connected to an ESP8266 and a Switch Item linked to a Zwave smart outlet and a Switch Item linked to the API for Kodi to turn on the TV.

Don’t want to use openHAB, cool. Your microcontrollers can can communicate with each other directly over MQTT, HA, Node Red, and I’m sure several other home automation platforms all speak MQTT too.

In short, esphome doesn’t support using the software as part of a larger system because all it cares about is the microcontroller. It provides a number of choices for an API, one of which is MQTT. To use it as part of a larger system, that larger system interacts with the microcontroller through one of those APIs. That’s how you build a wider system. Not by deploying mycropython modules here and there that somehow talk to each other through some low level “dictionary”.

Each device is a system unto itself with a sell defined API.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.