ESPHome and native API

[MarkoPaasila]

This is actually two questions: Should this work with esphome? What would it require to use valloxesp with the esphome/home-assistant native api?

[github-k8n]

Added retry logic in https://github.com/kotope/valloxesp/pull/35

As for the number components, i'm a bit at a loss how to integrate them in the external component (as optional subcomponent).. maybe @qvr has more input there ..

[qvr]

Haven't tried, but I think the number / button / other possible configurations could be done in the same component, as "Actions".

Example from a core component here: https://github.com/esphome/esphome/blob/dev/esphome/components/pzemdc/sensor.py#L67-L78 and then it would be used from the yaml definition like this: https://esphome.io/components/sensor/pzemdc.html#pzemdc-reset-energy-action

And if your device doesn't have those features, you'd just leave it out from the yaml definition, but it would still be a part of the component.

My reset service counter feature for the old custom component is here: https://github.com/qvr/valloxesp/commit/c62d88434d989e33d081634fbf5b4d72a9464e54 - that's a button that would look like this in HA:

[qvr]

...and the SDC30 component is a good example on how to register an action that can take value from the number sensor: https://github.com/esphome/esphome/blob/dev/esphome/components/scd30/sensor.py#L122-L134 https://esphome.io/components/sensor/scd30.html#manual-calibration

[github-k8n]

I'd welcome a PR for the climate.py file. (and everything else of course).

The actual part inside the vallox.cpp and vallox.h where it controls the device is quite simple once you have defined the control() and publish_state() somehow...

TBH I can't completely wrap my head around how the buttons/numbers are defined correctly as subcomponents, thus if you can make it work on that side, I'd be more than happy to adjust the code that actually does things :)

Keep in mind that we would need to have at least a "name" suboption like for the sensors (don't want to hardcode those), optionally maybe a default value (for the number component). The example in the peacefair is one level too high i think, it is a component of the top config itself..

in my opinion it should look like this to set up in the config yaml file:

heat_bypass:                   # full section optional
  name: vallox heat bypass   # required if option is enabled
  default: 23                      # optional for this section

reset_service_counter:               # section optional
  name: vallox reset service counter         # required if this section is enabled

(While it is great to have everything controllable that can be controlled, my personal requirements don't really include changing the interval or resetting the counter at the moment ... that's what I can do with the controller when I change the filter.... so my enthusiasm to put too much effort into this is somewhat limited...)

[qvr]

The button / number sensors would not be subcomponents, they would be separate entities in the yaml definition that you would leave out if not using them. They would just call the actions of the vallox component.

The yaml would look much like this currently does, but call the component actions instead of doing the custom class instantiation calls they now do: https://github.com/qvr/valloxesp/blob/c62d88434d989e33d081634fbf5b4d72a9464e54/esphome/Vallox.yaml#L89-L115

It's -25 C currently here, so I cant comfortably go breaking my current ventilation automations right now. Hopefully there were no other users using those features that you didn't need...

[github-k8n]

I guess at that temperature you probably don't want to enable/change summer bypass mode anyways :)

The config was intentionally kept as subcomponents of the climate: configuration, so having them partially below the other main parts like "number" or "binary_sensor" etc. was not the goal, instead having all below the "climate:" block which is the main required "type" of this device and has some optional controls/sensors. See for example the sprinkler integration for example of number components (however there it is one level too deep, below valves)

[github-k8n]

To be more specific the "multiplier_number" part of the sprinkler is basically exactly how we would need to configure it.

[sleepymaxx]

So now i have to make a update of all (your great) work and have to say Thank You!

Late reply because i did a new install with a new RS485 of the whole thing - and after replugging my Vallox went do Death- (i accidently switched the +/ - output from the buck converter to the ESP8266 D1 mini) First i thougt my whole Vallox died later i thougt i killed my FDB382 - finally and luckily it only was the 800mA fuse inside the Vallox.

After shock pause ----- + finding my error and Replacing the fuse i replugged and vóila all your Work runs fine.

[(Here i Recommend for anyone who´s doing this in future to explicit and always go from RX to RX to RXD0 pins on all boards also to go from TX ot TX to TXD0 and from + to the Ground(strange chinese icons) to the Ground on your ESP) as this ist the right understanding of a ModBUS]

Got all my sensors an so on running fine in Home Assistant will try to rename and integrate it correctly into my Home Assistant the next days. Last but not least there are some errors in the ESP-Home Logs. if you have the time for explaining or any idea of getting lost of the errors i will apreciate this very much.

[17:25:29][W][component:214]: Component vallox.climate took a long time for an operation (0.08 s). [17:25:29][W][component:215]: Components should block for at most 20-30ms.

ESP-HOME - Log without DEBUG: logs_wasseruhr-esp_run(4).txt

ESP-HOME - Log with DEBUG:
logs_wasseruhr-esp_run(5).txt

Actual. ESP Config: wasseruhr - esp.yaml.txt

Thank you again for your great work!

[github-k8n]

Glad to hear it's working :) If i remember correctly I also had to change the fuse once, seems the ones from the factory are prone to issues... (or maybe I also let the wrong wires touch ... who knows :D )

As for the "error", those are warnings, not errors, introduced in recent ESPHome versions that just mention that the component took "too long" to do its thing... basically when getting the data, evalutating it etc.. that took around 80ms in your case.

Basically the idea is to ensure that other components (wifi, logging, etc) have a chance to run as well (more of an issue with esp8266, with an esp32 the wifi part is done on the other CPU core...)

TL;DR: You can ignore that, shouldn't affect functionality...

[sleepymaxx]

R: You can ignore that, shouldn't affect functio

Right! Thanks again for your great work!

[github-k8n]

Ok, finally some progress. I got the number components to work. Next button press, hopefully I can finish it soon.

Small question to @qvr , which components are still missing in your opinion other than heat_bypass (number) and reset_service_counter (button) ?

[github-k8n]

@qvr , version with heat bypass control now in pull request, button will follow later.. https://github.com/kotope/valloxesp/pull/38

[github-k8n]

Now with setting to select the switch type and also fault details (variable 0x36) as text output https://github.com/kotope/valloxesp/pull/40

[HannuK0]

Hello and thanks for the great work!

There are couple features I would like to see implemented into the ESPHome version:

• Activation of the switch (button)
• Setting the fan speed (number)

[github-k8n]

Hello and thanks for the great work!

There are couple features I would like to see implemented into the ESPHome version:

* Activation of the switch (button)

* Setting the fan speed (number)

So just to verify, you want the fan speed as a separate control (i.e. duplicated from its current place in the climate control), right? Any specific reason for that?

[HannuK0]

So just to verify, you want the fan speed as a separate control (i.e. duplicated from its current place in the climate control), right? Any specific reason for that?

Sorry, I meant the default fan speed. My Vallox behaves like this: When changing the current fan speed directly on the device control panel it reverts back to the default fan speed after a while. I suspect it is because of the humidity sensor is controlling the fan speed.

[github-k8n]

Ok, added maximum and minimum/default fan speed controls. (fan_speed_max and fan_speed_min) (fan_speed_default sensor technically not necessary anymore but keeping for backwards compatibility right now.)

https://github.com/kotope/valloxesp/pull/41

(Switch button works here too now, waiting for this pull request to be accepted then doing another pull request adding the switch button probably tomorrow)

[github-k8n]

Switch button now added in https://github.com/kotope/valloxesp/pull/46

@kotope please merge :)

@HannuK0 please let me know if everything works as expected.

(Switch button works immediately but at the moment it could take up to 30 seconds until the switch binary sensor reflects the fact that the switch is active after you press the button in HA, not sure if that is the same if you press on the device itself but it is not pressing enough for me to investigate as the switch action can't be stopped and thus I don't want to play with it too much as it always takes time until i can test it again... )

If the (up to 30sec) delay of the sensor is an issue for you please let me know..

[sleepymaxx]

Hi again, im till today celebrating your great work... Thanks a lot!

But again im running into issues: I have installed two Humidity sensors and a CO² Sensor - they are working really fine in the integrated Vallox Display .. and from time to time also in HA.... (mostly once in the month... ) so a little bad.

In the original integrated Vallox steering module the CO² sensor is polled only from time to time (i think somehow between 40sec. to 1 minute or so) between these times you can access the steering and only read the last value of humidity +CO² ### AND WHILE CLAULATING THE HUMIDITY STATUS the Original steering module can´t be acessed or even the inputs won´t be noticed.

So i had the following idea: (Accordingly to my former mentioned issues:

[[17:25:29][W][component:214]: Component vallox.climate took a long time for an operation (0.08 s).

[17:25:29][W][component:215]: Components should block for at most 20-30ms.]

and the Behavior of the Original Vallox humidity display i think the Steering is outlasted by calculating the CO² measurement and cant be accessed. So also if i pull any information while the CO² calculating is done these information can´t be read out of the Vallox.

So my question here is: Is there a way to interrupt the outreadings when the calculating is done or can we give more time for the UART Bus to wait for the information..... also i tried to change the polling time by home assistant - sadly without a positive change...

If it´s too much work please forget about it... the integration is working too fine and im using the measurements of the integrated sensors in pretty much of my other automations... (its only some kind of luxury problem so i can get much more consistent graphic outreadings and a better understanding of my house... )

Thanks for your answer...

[github-k8n]

I know that there are still some issues. I was thinking about maybe re-doing the whole data reading/writing logic to make it as some kind of state machine so that I can properly react to different scenarios (the different timings that are specified in the documentation to the protocol etc.) However as you might have noticed that is a kind of "nice to have" and I am a bit too lazy at the moment (it is probably just too hot ...).

Just as some kind of "success story" If you want to know your humidity I can really recommend the xiaomi BT thermometers (there are bundles with just a few of them available if you don't want to go all in, but make sure that they are the same, basically look if the display looks exactly the same): https://www.kaufland.de/product/445201238/ then flash them with custom firmware (use OTA in Chrome) (the original firmware would also work with Home Assistant but it is WAAY to slow to send updates (like 5 min vs 10 seconds) https://github.com/pvvx/ATC_MiThermometer#readme then integrate them into Home Assistant using the BTHome integration. BUT be careful, the latest firmware doesn't seem to work anymore for flashing ... maybe try to get some "old stock" (see more on this on the github link above) You can also use simple ESP32 with ESPhome as bluetooth proxy so you have good reception if they are too far away for BLE to reach your Home Assistant.

(Got a bunch of them, one in every room and with hte custom firmware they are quick to react even with 0.01°C changes, so pretty cheap in total)

That way you can also check the humidity changes for example in the bathroom and increase the ventilation even if the overall humidity is not increasing that much.. (you can use the derivative helper sensor in HA to show you when the humidity changes quickly)

For the CO2 sensor I don't have a nice easy and cheap solution unfortunately ... but maybe when it gets colder maybe I can find some time to revisit this ... :)

TL;DR Maybe at some point in the future or maybe someone else can submit some pull request ...

[sleepymaxx]

All the time you are way much to fast for me.... - so i hope you will enjoy the great weather around you as long as possible... ;-) so i will wait with much patience if there will come some workaround.... as mentioned its only a luxury problem.

Your tips about other sensors are great and a very good idea! ... but i by myself am always looking for the maximum effort getting of the minimal used extra things...

Thank you again and have a nice end of summer... (we are also enjoing the great weather these days... )