Guidance for a new install

[Marat Bakeev]

Hi everyone.

Lots of info to process in these groups, could anyone help me out by answering a few questions?

I have homeassistant with two ACs connected to it and motorized dampers with esphome on them. Is there a way to control them through DZ somehow?

By sending MQTT commands or maybe there's an option to run a shell script or something?

I was planning to run DZ on a virtual machine, not on a RPi.

I really want a multizone control, and initially thought I'd have to write a custom integration for HASS, but I'm not sure my python skills are up to such a task, so I want to try DZ, but if what I want is impossible, maybe I need to look for something else?

Thanks

[Vadim Tkachenko]

Hello Marat,

> Lots of info to process in these groups, could anyone help me out by answering a few questions?

Be careful what you wish for, you may get it :)

> I have homeassistant with two ACs connected to it and motorized dampers with esphome on them. Is there a way to control them through DZ somehow?

Short answer: yes.

> By sending MQTT commands or maybe there's an option to run a shell script or something?

Longer answer: I haven't used ESPHome to control motorized dampers
yet, but that's a drop-in enhancement. What ESPHome component are you
currently using to control them? Can you please share hardware
details? Also, what hardware do you use to control your AC units?

> I was planning to run DZ on a virtual machine, not on a RPi.

Not a problem at all. I never got to officially running it in a Docker
container, but if you can package that and care to submit a PR -
that'll be most welcome.

> I really want a multizone control, and initially thought I'd have to write a custom integration for HASS, but I'm not sure my python skills are up to such a task, so I want to try DZ, but if what I want is impossible, maybe I need to look for something else?

It is perfectly possible.

DZ allows to have more zones than people usually think of (case in
point, my house has 11), you might want to install additional sensors
if you have big or high rooms, get them graphed with esphome2influxdb,
and see where you finally want the sensors to be (or even increase the
number of the zones).

--vt

[Marat Bakeev]

Thanks for answering! :)

Details:

> What ESPHome component are you currently using to control them? Can you please share hardware
details?

I have motorized dampers that work from 220V, and a bunch of robotdyn relay boards (these ones https://templates.blakadder.com/robotdyn_ESP32R4.html, https://www.aliexpress.com/item/1005003153036762.html). It's just a board with 4 relays, ESP32 and AC->DC converter.

They come with Tasmota on board, but I reflash them to ESPHome. Then it's just a time based cover - https://esphome.io/components/cover/time_based.html

Ideally, I would like to be able to 'modulate' the airflow, not just cut rooms off, but this was the easiest thing I could think of, before I found out about your project!

My original idea was that each damper+relay board would be a separate ESPHome thermostat, to serve as 'zone thermostat' - and the heating and cooling actions (a term in ESPhome 'thermostat' platform that specifies which actions to take, when you need to heat or cool - i.e. turn on AC) would send demands to an integration in HASS (Which I would have to write, and which would be able to react to different events... And which I want to avoid doing)

> Also, what hardware do you use to control your AC units?

For my ducted Gree I have their official modbus controller which is connected to yet another ESPHome, and that one has thermostat component which switches the AC on and off or from heat to cool. I tried using the Gree controller and its own sensors, but they're very weird, so instead I just set the wall controller to +16 when I need to cool down the house, or +30 when I need heat, and let ESPHome do the thinking. I have a bunch of zigbee and BLE sensors around the house, that are aggregated into an average value by HASS. The end result is that my office gets +27, and baby bedroom +21 -_-

For my panasonic wall split, I have another ESPHome on an ESP32 with 5V-3.3V Logic Converter and that esp32 runs this custom component - https://github.com/DomiStyle/esphome-panasonic-ac. I also thought that I would send commands by MQTT to this machine to turn it on or off.

Sorry for a wall of text :) Wanted to make sure I don't miss anything. So, TL;DR - I probably need to make DZ send commands to ESPHome through MQTT?

>  I never got to officially running it in a Docker container, but if you can package that and care to submit a PR - that'll be most welcome.

Sure, this I can definitely do, then it can run on my home kubernetes. I just need to figure out how to integrate DZ into the rest of my setup first :)

[Vadim Tkachenko]

Hello Marat,

Last question first: yes, MQTT for everything. The devil is in the details :)

> I have motorized dampers that work from 220V, and a bunch of robotdyn relay boards (these ones https://templates.blakadder.com/robotdyn_ESP32R4.html, https://www.aliexpress.com/item/1005003153036762.html). It's just a board with 4 relays, ESP32 and AC->DC converter.

Ha. Either I wasn't smart enough to look for a multi relay board, or
they were not available at the time, but this is what I got two years
ago: https://www.amazon.com/gp/product/B01NACU547 - you can use
several of them by connecting them to different pins (one goes on top,
and extras go separately, fits the breadboard). But I guess I'll get
myself a multi relay board so I could reproduce your setup - will
update on the exact product after I buy it and confirm it works.

> They come with Tasmota on board, but I reflash them to ESPHome. Then it's just a time based cover - https://esphome.io/components/cover/time_based.html

What made you want to use that component instead of a simple switch?
https://esphome.io/components/switch/index.html From what I know about
modern dampers, they are switch operated and move smoothly (though
yes, they do take some time). I'd say taking time to open/close into
account is an unnecessary complication, given the inertia of the whole
system. DZ keeps all dampers open when the HVAC units are off, so
there will not be extra stress due to excess static pressure.

What is the damper hardware that you're using?

> Ideally, I would like to be able to 'modulate' the airflow, not just cut rooms off, but this was the easiest thing I could think of, before I found out about your project!

This would be a bit tricky to do - DZ does support modulating dampers
as a concept (and works very well with them), however, there is no
standard protocol for them that I know about. There were several ideas
in the works - the most DZ compatible is to use the ESPHome Servo
component as that is a drop-in update for the existing control
component, also possible is PWM, and the most exotic and not yet
finished is the stepper.

> My original idea was that each damper+relay board would be a separate ESPHome thermostat, to serve as 'zone thermostat' - and the heating and cooling actions (a term in ESPhome 'thermostat' platform that specifies which actions to take, when you need to heat or cool - i.e. turn on AC) would send demands to an integration in HASS (Which I would have to write, and which would be able to react to different events... And which I want to avoid doing)

I like the last sentence :)

The difference between the way DZ does things and what other systems
[that I know of] do is, DZ feeds the *analog* signal into the zone
controller, whereas others feed on/off. Hence, it would be inadvisable
to use external thermostats, as it will severely degrade control
quality. The opposite is possible, though, you can feed DZ's HVAC
control signal into external HVAC systems.

> > Also, what hardware do you use to control your AC units?

> For my ducted Gree I have their official modbus controller which is connected to yet another ESPHome, and that one has thermostat component which switches the AC on and off or from heat to cool.

Having thought a bit about that... It is possible to coerce DZ to
issue a control signal to an ESPHome thermostat to turn the unit on or
off (specifically, the zone controller output). Not the nicest option,
and I hope to avoid it, it's an ugly hack.

Word of warning: DZ doesn't like the switch between heating and
cooling. The reason is, at some point I realized that heating and
cooling configuration for the house are totally, absolutely,
completely different, up to the point of using sensors in different
locations to control the same vents and HVAC units. It is easier to
just shut it down, point it to the different configuration and start
again.

Having said that... if the wheel squeaks loudly enough, this may get
done. I have a pretty clear idea about how to do it, just never got to
it.

> I tried using the Gree controller and its own sensors, but they're very weird, so instead I just set the wall controller to +16 when I need to cool down the house, or +30 when I need heat, and let ESPHome do the thinking. I have a bunch of zigbee and BLE sensors around the house, that are aggregated into an average value by HASS. The end result is that my office gets +27, and baby bedroom +21 -_-

Like that joke about the average temperature around the hospital,
including the morgue? :)

I'm curious, what ZigBee and BLE hardware you're using? You may have
noticed that there are basically two wireless interfaces DZ supports
natively - XBee (including the hardware driver) and MQTT, but
supporting more was always on my radar. From what I remember, Home
Assistant doesn't like ZigBee and Z-Wave that much, and (just took a
brief glance) BLE support is not that reliable on ESP, plus I don't
know if it'll satisfy my range requirements - but it might work for
others.

> For my panasonic wall split, I have another ESPHome on an ESP32 with 5V-3.3V Logic Converter and that esp32 runs this custom component - https://github.com/DomiStyle/esphome-panasonic-ac. I also thought that I would send commands by MQTT to this machine to turn it on or off.

Having taken a look at the project - I'd very much prefer to control
it over MQTT than to get in its guts. I blame Friday night, but I
didn't see the MQTT protocol description there. Did I miss it, or did
you mean to control its Home Assistant representation over MQTT? I
suspect the latter; it looks like the project is an extension of the
standard Climate component and yes, the ugly hack above will be
necessary to control that. Let me sleep on it.

> Sorry for a wall of text :) Wanted to make sure I don't miss anything.

No worries, we're in for a long haul. There are no stupid questions,
there are stupid answers.

> So, TL;DR - I probably need to make DZ send commands to ESPHome through MQTT?

Yep.

I just realized that so far DZ is a perfect MQTT consumer, but I don't
remember the status of it being an MQTT command producer - I know I
did it with at least Home Assistant and mqtt-automation-hat-go, but
don't remember HOW I did that off the top of my head. nor does it seem
documented. Let me go and dust that off.

[re-reading the whole message and correlating it to docs at the site]
Gawd, bit rot. ESPHome integration is much simpler by now, I need to
fix the docs.

> > I never got to officially running it in a Docker container, but if you can package that and care to submit a PR - that'll be most welcome.
> Sure, this I can definitely do, then it can run on my home kubernetes. I just need to figure out how to integrate DZ into the rest of my setup first :)

The first thing to do would be to figure out the system configuration,
zones, sensors, and actuators. I'd highly recommend mating it with
InfluxDB so that you can see the whole system in action. The best part
is, you don't have to have it all running at the same time -
individual components can be activated and instrumented, assuming
they're upstream in the dependency chain.

Here's some starting points:

https://github.com/home-climate-control/dz/wiki/HOWTO:-DZ-as-an-MQTT-Publisher
- this will make DZ visible to MQTT consumers, in particular, Home
Assistant
https://github.com/home-climate-control/dz/wiki/HOWTO:-DZ-to-Home-Assistant-integration
- the opposite
https://github.com/home-climate-control/dz/wiki/HOWTO:-MQTT-Sensors -
this should work, but is obsolete, update is coming

Good luck. More to come.

--vt

[Marat Bakeev]

Hi Vadim,

Sorry for the delay in answering, life happened (c)

Ha. Either I wasn't smart enough to look for a multi relay board, or
they were not available at the time,

Yeah, I think these boards are pretty new. Someone came up with them, and all other aliexpress shops are copying them.

 

> They come with Tasmota on board, but I reflash them to ESPHome. Then it's just a time based cover - https://esphome.io/components/cover/time_based.html

What made you want to use that component instead of a simple switch?
https://esphome.io/components/switch/index.html From what I know about
modern dampers, they are switch operated and move smoothly (though
yes, they do take some time). I'd say taking time to open/close into
account is an unnecessary complication, given the inertia of the whole
system. DZ keeps all dampers open when the HVAC units are off, so
there will not be extra stress due to excess static pressure.

This is a good question -  I guess ,I hoped that by using this component I could specify like 'open the vent at 30%'. For simplicity I might drop it, but my dampers are very dumb (and cheap) -

you have to keep sending power to the contact for it to work - so I have to keep the on or off relay until it's open (at least it has auto-stop when it reaches the end, but no feedback)

 

What is the damper hardware that you're using?

Some fellows run a shop with ventilation hardware, and I just bought them from that shop. I ordered one from aliexpress, but these local dampers are actually better - they have insulation and they are already here.

But it's literally a damper with a motor attached - here's a picture:

https://i.postimg.cc/jShV0q53/damper.jpg

> Ideally, I would like to be able to 'modulate' the airflow, not just cut rooms off, but this was the easiest thing I could think of, before I found out about your project!

This would be a bit tricky to do - DZ does support modulating dampers
as a concept (and works very well with them), however, there is no
standard protocol for them that I know about. There were several ideas
in the works - the most DZ compatible is to use the ESPHome Servo
component as that is a drop-in update for the existing control
component, also possible is PWM, and the most exotic and not yet
finished is the stepper.

Well, this is why I just wanted to try a timed cover component - there is no PWM for my damper motors, just two outputs for 220V. Maybe DZ could support timed cover too, if that's possible, for cases such as mine?

Or I think it's possible to emulate a servo component with some hacks on esphome side.

 

> My original idea was that each damper+relay board would be a separate ESPHome thermostat, to serve as 'zone thermostat' - and the heating and cooling actions (a term in ESPhome 'thermostat' platform that specifies which actions to take, when you need to heat or cool - i.e. turn on AC) would send demands to an integration in HASS (Which I would have to write, and which would be able to react to different events... And which I want to avoid doing)

I like the last sentence :)

The difference between the way DZ does things and what other systems
[that I know of] do is, DZ feeds the *analog* signal into the zone
controller, whereas others feed on/off. Hence, it would be inadvisable
to use external thermostats, as it will severely degrade control
quality. The opposite is possible, though, you can feed DZ's HVAC
control signal into external HVAC systems.

I don't have a requirement for external thermostats, as long as there's "an app" for that (which exists for DZ).

 

> > Also, what hardware do you use to control your AC units?

> For my ducted Gree I have their official modbus controller which is connected to yet another ESPHome, and that one has thermostat component which switches the AC on and off or from heat to cool.

Having thought a bit about that... It is possible to coerce DZ to
issue a control signal to an ESPHome thermostat to turn the unit on or
off (specifically, the zone controller output). Not the nicest option,
and I hope to avoid it, it's an ugly hack.

Again, I don't need to use ESPHome thermostat - it's just the stopgap solution I did for now, looking for a better one :)

Word of warning: DZ doesn't like the switch between heating and
cooling. The reason is, at some point I realized that heating and
cooling configuration for the house are totally, absolutely,
completely different, up to the point of using sensors in different
locations to control the same vents and HVAC units. It is easier to
just shut it down, point it to the different configuration and start
again.

Having said that... if the wheel squeaks loudly enough, this may get
done. I have a pretty clear idea about how to do it, just never got to
it.

Well, for me - it would be very desirable - springs and autumns in New Zealand are cold at night and hot during the day, so I really need it to be able to heat and cool. At night all rooms would require heating, but in the morning - my room heats up first, and needs to be cooled eventually, while other rooms in the house are still 'freezing to death'! :(

 

> I tried using the Gree controller and its own sensors, but they're very weird, so instead I just set the wall controller to +16 when I need to cool down the house, or +30 when I need heat, and let ESPHome do the thinking. I have a bunch of zigbee and BLE sensors around the house, that are aggregated into an average value by HASS. The end result is that my office gets +27, and baby bedroom +21 -_-

Like that joke about the average temperature around the hospital,
including the morgue? :)

Exactly that joke, yeah :)

 

I'm curious, what ZigBee and BLE hardware you're using? You may have
noticed that there are basically two wireless interfaces DZ supports
natively - XBee (including the hardware driver) and MQTT, but
supporting more was always on my radar. From what I remember, Home
Assistant doesn't like ZigBee and Z-Wave that much, and (just took a
brief glance) BLE support is not that reliable on ESP, plus I don't
know if it'll satisfy my range requirements - but it might work for
others.

For ZigBee - I think HASS now supports it nicely - I have a itead\sonoff zigbee usb stick which just plugs into one of the servers in the garage - the one that has a VM with HASS on it - https://sonoff.tech/product/diy-smart-switch/sonoff-zigbee-dongle-plus-efr32mg21/

For other sensors I also use Sonoff -  Sonoff TH01 (SNZB-02)  for temperature and humidity around the house, I also have a bunch of ZBMINI zigbee relays - they feed of mains and act as zigbee extenders (and are mounted inside wall switches, turning them from dumb to 'smart' ones)

For BLE - I used to have a raspberry pi in the center of the house, which would collect data from xiaomi LYWSDCGQ (https://esphome.io/components/sensor/xiaomi_ble.html#lywsdcgq) - but that often failed for hours at a time. I keep them as backups and also because they actually have screens on them (wife prefers real life things, not smart home dashboard :( )

 

> For my panasonic wall split, I have another ESPHome on an ESP32 with 5V-3.3V Logic Converter and that esp32 runs this custom component - https://github.com/DomiStyle/esphome-panasonic-ac. I also thought that I would send commands by MQTT to this machine to turn it on or off.

Having taken a look at the project - I'd very much prefer to control
it over MQTT than to get in its guts. I blame Friday night, but I
didn't see the MQTT protocol description there. Did I miss it, or did
you mean to control its Home Assistant representation over MQTT? I
suspect the latter; it looks like the project is an extension of the
standard Climate component and yes, the ugly hack above will be
necessary to control that. Let me sleep on it.

Well, I can just add MQTT subscribe to ESPhome that runs this component, and just set values with what I receive from MQTT?

 

> So, TL;DR - I probably need to make DZ send commands to ESPHome through MQTT?

Yep.

I just realized that so far DZ is a perfect MQTT consumer, but I don't
remember the status of it being an MQTT command producer - I know I
did it with at least Home Assistant and mqtt-automation-hat-go, but
don't remember HOW I did that off the top of my head. nor does it seem
documented. Let me go and dust that off.

[re-reading the whole message and correlating it to docs at the site]
Gawd, bit rot. ESPHome integration is much simpler by now, I need to
fix the docs.

I guess that's why I came asking questions, I do try to read the docs first!

 

> > I never got to officially running it in a Docker container, but if you can package that and care to submit a PR - that'll be most welcome.
> Sure, this I can definitely do, then it can run on my home kubernetes. I just need to figure out how to integrate DZ into the rest of my setup first :)

The first thing to do would be to figure out the system configuration,
zones, sensors, and actuators. I'd highly recommend mating it with
InfluxDB so that you can see the whole system in action. The best part
is, you don't have to have it all running at the same time -
individual components can be activated and instrumented, assuming
they're upstream in the dependency chain.

Here's some starting points:

https://github.com/home-climate-control/dz/wiki/HOWTO:-DZ-as-an-MQTT-Publisher
- this will make DZ visible to MQTT consumers, in particular, Home
Assistant
https://github.com/home-climate-control/dz/wiki/HOWTO:-DZ-to-Home-Assistant-integration
- the opposite
https://github.com/home-climate-control/dz/wiki/HOWTO:-MQTT-Sensors -
this should work, but is obsolete, update is coming

I've just started a new job, so my free time is limited, but I definitely will try to set this up this week!

Hope to hear more from you too, and thank you for the help and this amazing project!

[Vadim Tkachenko]

Hello Marat,

> Sorry for the delay in answering, life happened (c)

Welcome to the club :)

>> Ha. Either I wasn't smart enough to look for a multi relay board, or
>> they were not available at the time,
>
> Yeah, I think these boards are pretty new. Someone came up with them, and all other aliexpress shops are copying them.

For now, I'll make sure each of three HVAC relays is controlled by its
own MQTT topic, let's see how it works.

>> > They come with Tasmota on board, but I reflash them to ESPHome. Then it's just a time based cover - https://esphome.io/components/cover/time_based.html
>>
>> What made you want to use that component instead of a simple switch?
>> https://esphome.io/components/switch/index.html From what I know about
>> modern dampers, they are switch operated and move smoothly (though
>> yes, they do take some time). I'd say taking time to open/close into
>> account is an unnecessary complication, given the inertia of the whole
>> system. DZ keeps all dampers open when the HVAC units are off, so
>> there will not be extra stress due to excess static pressure.
>
> This is a good question - I guess ,I hoped that by using this component I could specify like 'open the vent at 30%'. For simplicity I might drop it, but my dampers are very dumb (and cheap) -
> you have to keep sending power to the contact for it to work - so I have to keep the on or off relay until it's open (at least it has auto-stop when it reaches the end, but no feedback)

I think you'd be better off using them as bang/bang dampers - it will
make the whole system simpler for now, and give you a good idea if
that is the bottleneck you want to optimize (my best guess is that
you'll be happy with them for a while).

>> > Ideally, I would like to be able to 'modulate' the airflow, not just cut rooms off, but this was the easiest thing I could think of, before I found out about your project!

[skipped]

> Well, this is why I just wanted to try a timed cover component - there is no PWM for my damper motors, just two outputs for 220V. Maybe DZ could support timed cover too, if that's possible, for cases such as mine?

Nope, too unreliable.

> Or I think it's possible to emulate a servo component with some hacks on esphome side.

Not quite emulate... https://github.com/home-climate-control/hcc-esp32
was born for this exact purpose, and is being kept alive for this
exact purpose - to provide fine motion control for servo or stepper
based dampers. That was before TK pushed me towards ESPHome, which
satisfied the needs for a long, long time. This is far from the top of
the priority list, but this is exactly where the damper controller
should be - real time requirements make it impossible to try to use
the server side for fine motion control (long story, take my word for
it).

> I don't have a requirement for external thermostats, as long as there's "an app" for that (which exists for DZ).

And don't forget, DZ exposes its thermostats to other home automation
solutions, so you can control and program them from anywhere. I found
it best to control them via Google Calendar integration, though (in
addition to manual control, of course - but soon you forget about the
manual control, It Just Works).

>> Word of warning: DZ doesn't like the switch between heating and
>> cooling. The reason is, at some point I realized that heating and
>> cooling configuration for the house are totally, absolutely,
>> completely different, up to the point of using sensors in different
>> locations to control the same vents and HVAC units. It is easier to
>> just shut it down, point it to the different configuration and start
>> again.
>>
>> Having said that... if the wheel squeaks loudly enough, this may get
>> done. I have a pretty clear idea about how to do it, just never got to
>> it.
>
> Well, for me - it would be very desirable - springs and autumns in New Zealand

Ha :) You're not alone in New Zealand :) You guys maybe even live
within walking distance from each other, with some luck.

> are cold at night and hot during the day, so I really need it to be able to heat and cool. At night all rooms would require heating, but in the morning - my room heats up first, and needs to be cooled eventually, while other rooms in the house are still 'freezing to death'! :(

Noted. I'd question the insulation quality if your rooms need both
heating and cooling throughout the day. Also, there's a contraption in
DZ intended to reduce the cost of cooling or heating - the economizer,
it uses the "whole house fan" concept. Improved version is in the
works, I'll be dogfooding it this season, so you can count on it. Just
so you know, the hardware I'm using here is AC Infinity - the S6 is
enough to deal with a medium size bedroom at about 1/3 max airflow,
and S8 is enough to deal with a 850 sq ft workshop. Don't bother with
the T models - though by themselves they are awesome, at least as an
idea. They are also a well designed product (quoting a mechanical
engineer here).

Running late, so the rest of your message will get answered tomorrow.

--vt

[Vadim Tkachenko]

Hello Marat,

[part 2]

On Tue, Aug 30, 2022 at 12:09 AM Marat Bakeev <haw...@gmail.com> wrote:

>> I'm curious, what ZigBee and BLE hardware you're using? You may have
>> noticed that there are basically two wireless interfaces DZ supports
>> natively - XBee (including the hardware driver) and MQTT, but
>> supporting more was always on my radar. From what I remember, Home
>> Assistant doesn't like ZigBee and Z-Wave that much, and (just took a
>> brief glance) BLE support is not that reliable on ESP, plus I don't
>> know if it'll satisfy my range requirements - but it might work for
>> others.
>
> For ZigBee - I think HASS now supports it nicely - I have a itead\sonoff zigbee usb stick which just plugs into one of the servers in the garage - the one that has a VM with HASS on it - https://sonoff.tech/product/diy-smart-switch/sonoff-zigbee-dongle-plus-efr32mg21/

I'm using Aeotec hardware, but that's not ZigBee, that's Z-Wave. Now
trying to remember why I chose it over ZigBee (except XBee devices
that ran over ZigBee for over a decade) and thinking that it was
probably because the only remote heavy duty switch with an energy
meter that I could get at the time was working over ZigBee:
https://www.amazon.com/gp/product/B00MBIRF5W

> For other sensors I also use Sonoff - Sonoff TH01 (SNZB-02) for temperature and humidity around the house, I also have a bunch of ZBMINI zigbee relays - they feed of mains and act as zigbee extenders (and are mounted inside wall switches, turning them from dumb to 'smart' ones)
>
> For BLE - I used to have a raspberry pi in the center of the house, which would collect data from xiaomi LYWSDCGQ (https://esphome.io/components/sensor/xiaomi_ble.html#lywsdcgq) - but that often failed for hours at a time. I keep them as backups and also because they actually have screens on them (wife prefers real life things, not smart home dashboard :( )

I use I2C BME280 on ESP8266 boards (pictured here:
https://www.homeclimatecontrol.com/hcc-esp), BME680 also works but the
VOC sensor turned out pretty useless (or, maybe, I didn't dive deep
enough into how to properly use it). HTU21D-F is also possible (you
lose barometric pressure), but the price being comparable with BME280,
I usually buy those.

Lately, we procured some screens (and the board above has an embedded
NeoPixel), so you might get the best of both worlds at some point -
though, of course, with the disadvantage of running over WiFi (and
possible WiFI blackouts killing the sensor network; this happens more
often than it happens with XBee), and I doubt we'll get the packaging
to production quality, this is out of scope.

>> > For my panasonic wall split, I have another ESPHome on an ESP32 with 5V-3.3V Logic Converter and that esp32 runs this custom component - https://github.com/DomiStyle/esphome-panasonic-ac. I also thought that I would send commands by MQTT to this machine to turn it on or off.
>>
>> Having taken a look at the project - I'd very much prefer to control
>> it over MQTT than to get in its guts. I blame Friday night, but I
>> didn't see the MQTT protocol description there. Did I miss it, or did
>> you mean to control its Home Assistant representation over MQTT? I
>> suspect the latter; it looks like the project is an extension of the
>> standard Climate component and yes, the ugly hack above will be
>> necessary to control that. Let me sleep on it.
>
> Well, I can just add MQTT subscribe to ESPhome that runs this component, and just set values with what I receive from MQTT?

Yes, that's the way it'll work.

>> [re-reading the whole message and correlating it to docs at the site]
>> Gawd, bit rot. ESPHome integration is much simpler by now, I need to
>> fix the docs.
>
> I guess that's why I came asking questions, I do try to read the docs first!

Coming up.

> I've just started a new job, so my free time is limited, but I definitely will try to set this up this week!

Take your time, I also have some catching up to do on this end.


--vt

[Vadim Tkachenko]

Hello Marat,

On Tue, Aug 30, 2022 at 12:09 AM Marat Bakeev <haw...@gmail.com> wrote:
>

> Sorry for the delay in answering, life happened (c)

Looks like a lot of life is happening to all of us these days :)

>> Ha. Either I wasn't smart enough to look for a multi relay board, or
>> they were not available at the time,
>
> Yeah, I think these boards are pretty new. Someone came up with them, and all other aliexpress shops are copying them.
>
>> > They come with Tasmota on board, but I reflash them to ESPHome. Then it's just a time based cover - https://esphome.io/components/cover/time_based.html

I got this relay board, thanks to TK for the suggestion:
https://www.amazon.com/dp/B09XWWYK4V - note, you need at least one
T-U2T adapter to flash it. Works nicely, though mechanically a two
hole mount is not the best, you'd probably want to print a support
bracket not to strain it too much. ESPHome based switches are now
supported natively (ESPHomeSwitch in reactive branch), two of these
boards are now being tested as a replacement for 12 year old XBee Pro
based boards.

>> Word of warning: DZ doesn't like the switch between heating and
>> cooling. The reason is, at some point I realized that heating and
>> cooling configuration for the house are totally, absolutely,
>> completely different, up to the point of using sensors in different
>> locations to control the same vents and HVAC units. It is easier to
>> just shut it down, point it to the different configuration and start
>> again.
>>
>> Having said that... if the wheel squeaks loudly enough, this may get
>> done. I have a pretty clear idea about how to do it, just never got to
>> it.
>
> Well, for me - it would be very desirable - springs and autumns in New Zealand are cold at night and hot during the day, so I really need it to be able to heat and cool. At night all rooms would require heating, but in the morning - my room heats up first, and needs to be cooled eventually, while other rooms in the house are still 'freezing to death'! :(

Since that time, I got the second generation economizer module working
- and managed to get it just in time to catch the last glimpse of free
cooling before the winter hit; it looks like it is quite possible to
have the HVAC and the economizer to be set to opposite modes and have
them configured in a way that doesn't make them fight each other. I
don't know when the season crossover is happening at your location,
here, it'll come in late January - early February, so hopefully I'll
get some more data and fine tuning before your crossover comes.

> For ZigBee - I think HASS now supports it nicely - I have a itead\sonoff zigbee usb stick which just plugs into one of the servers in the garage - the one that has a VM with HASS on it - https://sonoff.tech/product/diy-smart-switch/sonoff-zigbee-dongle-plus-efr32mg21/
>
> For other sensors I also use Sonoff - Sonoff TH01 (SNZB-02) for temperature and humidity around the house, I also have a bunch of ZBMINI zigbee relays - they feed of mains and act as zigbee extenders (and are mounted inside wall switches, turning them from dumb to 'smart' ones)

Interestingly enough, I ended up buying the same sensor for R&D
independently of what you wrote - I only remembered about this post
and looked at it after the hardware arrived.

I will be closely investigating SNZB-02 in coming days - its modus
operandi is different from the usual HCC sensors; it expects a
continuous data flow from them to support decent control quality. 30
seconds between measurements is as high as I ever got, higher latency
would cause overshoots. SNZB-02, on the other hand, seems to report
the temperature only upon change, and the resolution observed so far
is at best 0.2°C. I'm yet to dig deeper into its docs and
configuration, so I'll reserve my judgment about whether it is
suitable for HCC use until later.

The task for tonight is: extend recent additions to ESPHome and Z-Wave
family to Zigbee devices. Shouldn't be too hard, the only difference
is the MQTT message payload format.

> Well, I can just add MQTT subscribe to ESPhome that runs this component, and just set values with what I receive from MQTT?

Updated answer: Yes.

>> > So, TL;DR - I probably need to make DZ send commands to ESPHome through MQTT?
>>
>> Yep.

Updated answer: Yes, for ESPHome, Z-Wave JS UI, and zigbee2mqtt (coming up now).

>> I just realized that so far DZ is a perfect MQTT consumer, but I don't
>> remember the status of it being an MQTT command producer - I know I
>> did it with at least Home Assistant and mqtt-automation-hat-go, but
>> don't remember HOW I did that off the top of my head. nor does it seem
>> documented. Let me go and dust that off.

Updated answer: Yes.

--vt

[Tim Peterson]

On Tue, Nov 15, 2022 at 5:42 PM Vadim Tkachenko <v...@homeclimatecontrol.com> wrote:

I will be closely investigating SNZB-02 in coming days - its modus
operandi is different from the usual HCC sensors; it expects a
continuous data flow from them to support decent control quality. 30
seconds between measurements is as high as I ever got, higher latency
would cause overshoots. SNZB-02, on the other hand, seems to report
the temperature only upon change, and the resolution observed so far
is at best 0.2°C. I'm yet to dig deeper into its docs and
configuration, so I'll reserve my judgment about whether it is
suitable for HCC use until later.

I have the same Zigbee bridge and sensors as you do, and I've been monitoring them in Home Assistant for several months now through zigbee2mqtt. Just like you, almost as soon as I started looking at the graphs I realized that it would be hard to do fine-grained control using this data, as it sends an update only when either a minimum or maximum (30 minutes) time threshold or a temperature delta threshold is reached. While I haven't examined the data in detail, it seems that the values it reports have significantly higher resolution than the temperature delta threshold. For instance, at a quick glance I see two samples spaced exactly 30 minutes apart that differ by only 0.05F. When using these sensors to monitor the cooling operation of a basic digital thermostat, I'm lucky if I can distinguish the temperature cycling from random noise, as the graph only bounces by one delta count each cycle. I have also had some occasional hours-long data gaps, even from the sensor that's located less than ten feet from the bridge. It's pretty clear that if I want to roll my own controls I'll definitely need to use sensors that aren't engineered for long battery life like these are.

Hope this helps.

--Tim

[Tomasz Korwel]

I'm having hard time understanding your (and Vadim's) obsession with data resolution. :)

Here is how I see things. The sensor reports data when:

- the value changed by set value

- the certain amount of time passed (in my case 30 min)

(I'm using Tuya zigbee sensors)

so let's say over 60 minutes period I'm receiving:

00:00 - 21C

00:12 - 21.2C

00:18 - 21.5C

00:48 - 21.5C (30 min heartbeat report)

how does it differ from:

00:00 - 21C

00:01 - 21C

00:02 - 21C

.....

00:11 - 21C

00:12 - 21.2C

00:13 - 21.2C

and so on?

Yes, it would be nice to have that 21.1C captured somewhere, but is it really that important? People can't sense those differences anyway.

Unless your hvac system is so responsive that waiting 10 minutes will grossly overshoot target this resolution is more than enough.

--

---
You received this message because you are subscribed to the Google Groups "DIY Zoning & Home Climate Control Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to home-climate-con...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/home-climate-control/CA%2Bhv5qk9%2BywReciRNZj8KC_bLgU7PLbm7eyFro_-t4TzHY2zuQ%40mail.gmail.com.

[Vadim Tkachenko]

Hello Tim,

On Sun, Nov 20, 2022 at 6:37 PM Tim Peterson <t...@timpeterson.org> wrote:

On Tue, Nov 15, 2022 at 5:42 PM Vadim Tkachenko <v...@homeclimatecontrol.com> wrote:

I will be closely investigating SNZB-02 in coming days - its modus
operandi is different from the usual HCC sensors; it expects a
continuous data flow from them to support decent control quality. 30
seconds between measurements is as high as I ever got, higher latency
would cause overshoots. SNZB-02, on the other hand, seems to report
the temperature only upon change, and the resolution observed so far
is at best 0.2°C. I'm yet to dig deeper into its docs and
configuration, so I'll reserve my judgment about whether it is
suitable for HCC use until later.

I have the same Zigbee bridge and sensors as you do, and I've been monitoring them in Home Assistant for several months now through zigbee2mqtt. Just like you, almost as soon as I started looking at the graphs I realized that it would be hard to do fine-grained control using this data, as it sends an update only when either a minimum or maximum (30 minutes) time threshold or a temperature delta threshold is reached.

I overcame that; the pictures are at the bottom so as not to interfere with the flow. I set the reporting on the sensor to (1, 60, 5), and you can see the difference that it makes.

It looks like the sensor is now sending the samples every 10 to 30 seconds. Battery voltage dropped from 3.3V to 3.1V since, but it still reports itself at 100%. Unfortunately, HA doesn't capture neither the voltage nor the link quality, and default settings report battery more than at least two days apart. I can concoct an MQTT listener for that, but it's not a priority until it is determined if this sensor can be used at all (so far, I think it'll be just fine, likely will connect it to the production instance tonight).

While I haven't examined the data in detail, it seems that the values it reports have significantly higher resolution than the temperature delta threshold. For instance, at a quick glance I see two samples spaced exactly 30 minutes apart that differ by only 0.05F. When using these sensors to monitor the cooling operation of a basic digital thermostat, I'm lucky if I can distinguish the temperature cycling from random noise, as the graph only bounces by one delta count each cycle. I have also had some occasional hours-long data gaps, even from the sensor that's located less than ten feet from the bridge. It's pretty clear that if I want to roll my own controls I'll definitely need to use sensors that aren't engineered for long battery life like these are.

More about that in the next message, coming up shortly.

 

--Tim

--vt

PS: 

- First: since the beginning (including gaps when the zigbee2mqtt dev host was down);

- Second: original settings;

- Third: (1, 60, 5) above;

- Fourth: comparison between humidity (default settings) and temperature samples.

Note the different time span on all four. Also note the noise on the third.

[Vadim Tkachenko]

Hello Tomasz,

> I'm having hard time understanding your (and Vadim's) obsession with data resolution. :)

Meanwhile, I'm having a hard time understanding why you call this an
obsession :) It's a simple engineering caveat, not even a problem.
Read on.

> Here is how I see things. The sensor reports data when:
> - the value changed by set value
> - the certain amount of time passed (in my case 30 min)
> (I'm using Tuya zigbee sensors)
>
> so let's say over 60 minutes period I'm receiving:
> 00:00 - 21C
> 00:12 - 21.2C
> 00:18 - 21.5C
> 00:48 - 21.5C (30 min heartbeat report)
>
> how does it differ from:
> 00:00 - 21C
> 00:01 - 21C
> 00:02 - 21C
> .....
> 00:11 - 21C
> 00:12 - 21.2C
> 00:13 - 21.2C
> and so on?

Implementation details. I'm sure you know that PID controllers will
change the output signal even when the input signal doesn't change.
Original DZ implementation demanded sensors to check in at intervals
to maintain control quality (can you read a sensor once in 10 minutes?
Sure, but be ready to deal with integral windup et al). Today, the
reactive rewrite is more lenient about that, and it will be even more
lenient to accommodate energy efficient sensors. So, technically, even
the constant sensor data flow is not necessary, but the PID controller
computation heartbeat is. In absence of an actual signal reading, it
assumes it unchanged until the timeout, and then acts upon it.

> Yes, it would be nice to have that 21.1C captured somewhere, but is it really that important? People can't sense those differences anyway.

It's not for people, it's for control logic :)

> Unless your hvac system is so responsive that waiting 10 minutes will grossly overshoot target this resolution is more than enough.

See above - yes, there was an overshoot before.

You touched an interesting problem here - sensor temperature inertia,
and, on a tangent, noise.

Originally, I used bare DS1820 sensors which have little to none
temperature inertia - you blow on it, it senses it. I2C sensors have
higher inertia even bare, all of them become significantly duller when
put in a box, and Z-Wave and Zigbee sensors come boxed out of the box,
no pun intended. Thankfully, PID tuning addresses that - but my
personal preference is to have a crazy light sensor with high time and
signal resolution and dull it with PID than to have a dull sensor and
deal with its noise. In the first case, I can control the noise (HCC
has several filters in it today, you can play with them, names below,
and more will be coming after the reactive overhaul dust settles).

So, if the settings I'm using on SNZB-02 don't kill the battery, I'd
rather play with them and use standard PID settings (a good default is
P=1 I=0.000004 saturationLimit=1.1) than to make the whole system
cough and sneeze when the sensor decides to emit a noisy value. PID
controller will have much less space to deal with noise then,
especially if the time resolution is poor.

Though, it's theoretically possible to insert an extrapolator into the
data stream - but I'll be blunt, that's nowhere on my list :) However,
if someone wants to do it, I'm all for it - look at SignalProcessor
interface and existing filters' implementation, it should be pretty
simple.

Now, filters, off the top of my head:

FallbackFilter - more than one sensor in a chain of command (one
fails, the other is picked up)
MedianFilter - median filtering on a single sensor data stream
MedianSetFilter - median filtering on a set of data streams, the
"middle stream" wins (careful with this one, it *will* jump when one
or more of the streams fail)

--vt

[Vadim Tkachenko]

Hello lurkers,

On Mon, Nov 21, 2022 at 11:46 AM Tomasz Korwel <tom...@korwel.net> wrote:
>
> I'm having hard time understanding your (and Vadim's) obsession with data resolution. :)

Another ¢2 - see the picture below; green is SONOFF SNZB-02 programmed to provide data with 2 decimal points, yellow is Aeotec ZWA005 (TriSensor) programmed to issue readings every 30 seconds, located about 200mm from each other. On one hand, SNZB-02 emits the signal stream I will rather theoretically take over the other any time of day, even with noise (which can be easily filtered out and is smoothed by PID anyway, see my earlier posts) because it shows the trend better, on the other hand, resolution on TriSensor was set to 0.1° which is totally enough for both display and control purposes (and for display purposes it's probably even better because it will give the users a [false?] sense of stability and not cause them to fidget and check it every few seconds.

Just for giggles, I might set up two thermostats and collect PID charts for them (which, by the way, the reactive branch is doing by default now without the need to configure splitters), but if anyone wants to beat me to it, I'd rather do something productive instead :)

So, my verdict: 0.1° every 30 seconds is good enough for indoor control, assuming it doesn't kill the battery.

--vt

PS: Practical considerations - oh my, are those devices fiddly. This particular Zigbee sensor is much more pleasant to work with, for I can configure it with no fuss, whereas the TriSensor needs to be woken up by hand to accept the configuration, it reports itself as sleeping and is apparently not listening to commands even though it emits the data stream.