Installed the d1 with print and working as described
Its to bad that we are not able to put the Itho in AUTO mode via the ESP8266 as well.
This reduces the functionality....
This is only possible via the remote as designed :-(
I will build a 433 remote on top of a Wemos D1
Regards !

Hi Arjen,

Would it be possible to have the current speed level visible in a numbered scale 0-254? or just a single current speed number?

Kind regards,
Rob

Could you explore the possibility of implementing the auto discovery feature via mqtt of the ithowifi device within Home Assistant?

Example given
https://www.zigbee2mqtt.io/integration/home_assistant.html

Reference
https://developers.home-assistant.io/docs/device_registry_index/

Describe the bug
After starting the add-on the temperature measurement works correctly, but after a while it remains stuck on a certain value. After reoot temperature works again. The same stuck value is visible in the web interface and in the MQTT messages.

To Reproduce
Start add-on and look at temperature readings.
Wait.

Expected behaviour
Correct temperature reading.

Screenshots

Device information

• Firmware version: 2.3-beta6
• Hardware revision: 2
• Type/model number Itho: CVE-S ECO HE (03-00402)
• CC1101 RF module enabled: no
• In case of wifi issues, wifi access point make and model: not relevant

Debug logging
Please provide debug logging from the debug page if possible:

2021-11-24 17:18:59 N: System boot, last reset reason: SDIO_RESET
2021-11-24 17:18:59 N: HW rev: 2, FW ver.: 2.3-beta4
2021-11-24 17:19:00 N: wifi config saved
2021-11-24 17:19:00 N: Setup: Wifi config load failed
2021-11-24 17:19:01 N: wifi AP mode started
2021-11-24 17:19:01 N: Setup: AP mode active
2021-11-24 17:19:01 N: Setup: Virtual remote ID: 60,244,252
2021-11-24 17:19:01 N: Webserver: started
2021-11-24 17:19:01 N: mDNS: started
2021-11-24 17:19:01 N: Hostname: ***************
2021-11-24 17:19:01 N: Setup: done
      2159 N: System boot, last reset reason: SDIO_RESET
      2177 N: HW rev: 2, FW ver.: 2.3-beta4
      2215 N: Setup: Wifi config load failed
      3891 N: wifi AP mode started
      3911 N: Setup: AP mode active
      3929 N: Setup: Virtual remote ID: 60,244,252
      3957 N: Webserver: started
      3978 N: mDNS: started
      3999 N: Hostname: ***************
      4019 N: Setup: done
    137034 N: wifi config saved
      2159 N: System boot, last reset reason: SDIO_RESET
      2178 N: HW rev: 2, FW ver.: 2.3-beta4
      8642 N: WiFi: connection successful
      8661 N: WiFi info:
      8679 N: Mode:STA
      8697 N: Status:3
      8716 N: IP:***************
      8734 N: Setup: Virtual remote ID: 60,244,252
      8760 N: Webserver: started
      8781 N: mDNS: started
      8799 N: Hostname: ***************
      8819 N: Setup: done
    233456 N: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
  21600022 N: Mem free: 165252, Mem low: 133168, Mem block: 97392
  43200045 N: Mem free: 157128, Mem low: 133168, Mem block: 97392
  44273018 N: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
  64800077 N: Mem free: 165164, Mem low: 133156, Mem block: 91376
  86400114 N: Mem free: 164980, Mem low: 123456, Mem block: 97392
 108000156 N: Mem free: 164976, Mem low: 123456, Mem block: 97392
 128950070 N: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
 129600196 N: Mem free: 164864, Mem low: 123456, Mem block: 97392
 130791107 N: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
 151200237 N: Mem free: 164676, Mem low: 123456, Mem block: 97392
 157852763 N: Firmware update: nrgitho-hw2-v2.3-beta6.bin
 157870173 N: Reboot requested
      2159 N: System boot, last reset reason: SDIO_RESET
      2178 N: HW rev: 2, FW ver.: 2.3-beta6
      5648 N: WiFi: connection successful
      5667 N: WiFi info:
      5685 N: Mode:STA
      5703 N: Status:3
      5722 N: IP:***************
      5741 N: Setup: Virtual remote ID: 60,244,252
     11565 N: MQTT: connected, System config: 1
     11593 N: Webserver: started
     11614 N: mDNS: started
     11633 N: Hostname: ***************
     11654 N: Setup: done
     15313 N: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
  21600023 N: Mem free: 152928, Mem low: 122720, Mem block: 96352
  43200052 N: Mem free: 162192, Mem low: 122672, Mem block: 96352
  55786428 N: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
  64800090 N: Mem free: 162088, Mem low: 122672, Mem block: 96352
  86400125 N: Mem free: 160740, Mem low: 122672, Mem block: 96352
 108000170 N: Mem free: 160732, Mem low: 122672, Mem block: 96352
 129600204 N: Mem free: 161892, Mem low: 122672, Mem block: 96352
 144098236 N: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
 151200237 N: Mem free: 161684, Mem low: 122672, Mem block: 96352
 172800265 N: Mem free: 161684, Mem low: 122672, Mem block: 90336

Desktop (please complete the following information):
Not relevant. Issue on both web interface as MQTT

Smartphone (please complete the following information):
Not relevant. Issue on both web interface as MQTT

When manual control is set to 1, one is allowed to manually control the position of the valve by setting the value for manual_value_position - the value is really moved to the desired position, however the value is not reflected in Itho settings.

HW revision: 2
fw ver.: nrgitho-hw2-v2.3-beta2.bin
unit: WTW HRU 350 ECO

I think it would be nice to have a 'export to pdf' function on the 'Itho Settings' page.
Maybe even a reminder to export the current settings when a settings is about to be changed.

For monitoring if the add-on is online, it would me nice if a "last-will topic" can be set by the MQTT client in the firmware.
If then the wifi add-on disconnects unexpectedly from the MQTT broker for whatever reason, the MQTT broker will automatically notify all connected clients.

I'm not into ESP8266 programming, but I think it's a matter of:

• Adding a setting in the web interface for the will-topic name,
• Adding an argument in the connect function, with the willTopic name and willMessage. (https://pubsubclient.knolleary.net/api.html#connect ?). The broker will automatically post the willMessage (for example "offline"), to the willTopic, when the add-on disconnects.
• On startup of the add-on, it should publish a retained "online" message to the will-topic

This way, by looking at the last retained message in the will topic, it's easy to check if device is online or offline.

See also:

• https://www.home-assistant.io/docs/mqtt/birth_will/ (although last will message is useful in any home automation system, not only in Home Assistant)

Is it possible to add an option to MQTT to show who issued the command?
E.g remote 1, remote 2, web?

Please add support for the remote/thermostat module https://www.ithodaalderop.nl/nl-NL/professional/product/03-00476. This remote contains an RF transceiver which seems to pair two-way with the fan.

I needed I can help by supplying logs or dumps.

It would be nice to have a way of dumping all of the current itho settings (mainly the factory defaults) in a form of a json to the SPIFFS (and have it available for a download) for backup or various profiles purposes.

Same way the feature could accept a json with such mappings to bulk apply the values on the specified indexes.

Describe the bug
Non-CVE unit with latest firmware doesn't detect CC1101 properly. This is showing up when connected to either WPU or HRU-350. This used to work fine but I cannot recall since when it didn't work as I had format the add-on and switched it between HRU and WPU as I only had 1 device.

To Reproduce
Steps to reproduce the behaviour:

1. Go to System settings
2. Enable Itho RF Remote Support
3. Reboot
4. Device should be available immediately but it's then inaccessible
5. When the add-on web page is eventually is available CC1101 is disabled in the menu

Expected behaviour
RF Remotes shown in left menu, immediate availability.

Debug logging
Logs:
2021-11-27 13:08:17 N: IP:192.168.178.37
2021-11-27 13:08:17 N: Setup: Virtual remote ID: 128,223,108
2021-11-27 13:08:17 N: Webserver: started
2021-11-27 13:08:18 N: Setup: init of CC1101 RF module successful
2021-11-27 13:08:18 N: mDNS: started
2021-11-27 13:08:18 N: Hostname: wpu
7377 N: Setup: done
2021-11-27 13:08:26 N: System boot, last reset reason: DEEPSLEEP_RESET
2021-11-27 13:08:26 N: HW rev: NON-CVE 1, FW ver.: 2.3-beta6
2021-11-27 13:08:31 N: WiFi: connection successful
2021-11-27 13:08:31 N: WiFi info:
2021-11-27 13:08:31 N: Mode:STA
2021-11-27 13:08:31 N: Status:3
2021-11-27 13:08:31 N: IP:192.168.178.37
2021-11-27 13:08:31 N: Setup: Virtual remote ID: 128,223,108
2021-11-27 13:08:31 N: Webserver: started
2021-11-27 13:08:31 N: mDNS: started
2021-11-27 13:08:31 N: Hostname: wpu
2021-11-27 13:08:31 N: Setup: done
2021-11-27 13:08:33 N: Setup: init of CC1101 RF module failed
2021-11-27 13:08:37 N: System boot, last reset reason: SDIO_RESET
2021-11-27 13:08:37 N: HW rev: NON-CVE 1, FW ver.: 2.3-beta6
2021-11-27 13:08:42 N: WiFi: connection successful
2021-11-27 13:08:42 N: WiFi info:
2021-11-27 13:08:42 N: Mode:STA
2021-11-27 13:08:42 N: Status:3
2021-11-27 13:08:42 N: IP:192.168.178.37
2021-11-27 13:08:42 N: Setup: Virtual remote ID: 128,223,108
2021-11-27 13:08:42 N: Webserver: started
2021-11-27 13:08:42 N: mDNS: started
2021-11-27 13:08:42 N: Hostname: wpu
2021-11-27 13:08:42 N: Setup: done

Device information

• Firmware version [e.g. 2.2.1] 2.3-b6
• Hardware revision (e.g. non-cve 1.1) non-cve 1
• Type/model number Itho (on sticker outside the box) HRU-350
• CC1101 RF module enabled [ yes, no ] yes
• In case of wifi issues, wifi access point make and model: N/A

Desktop (please complete the following information):

• OS: [e.g. iOS] MacOS Monterey
• Browser [e.g. chrome, safari] Safari
• Version [e.g. 22] 15

Problem:
Today MQTT auto-discovery for Home Assistant uses the fan speed. This is not available for non-CVE

Proposed solution
Change the MQTT payload for HA auto-discovery to something like this:

{
"name": "XXX", 
"uniq_id":"YYY", 
"stat_t":"itho/lastcmd",
"stat_val_tpl":"ON",
"pr_modes":["low","medium","high","timer1","timer2","timer3"],
"cmd_t":"itho/cmd",
"pr_mode_cmd_t":"itho/cmd",
"pr_mode_stat_t":"itho/lastcmd",
"pr_mode_val_tpl":"{{ value_json.command }}"
}

The fan still has an on/off but I don't think that makes sense with non-CVE as low is the option available and not a true off (speed = 0).

Changing preset via HA from medium to high.
Output of : mosquitto_sub -F "@y-@m-@dt@H:@m:@s@z %t %p" -u XXXX -P XXX -h localhost -t "itho/#"

2021-11-03T10:18:04+0100 itho/lastcmd {"source":"MQTT API","command":"medium","timestamp":1635930662}
2021-11-03T10:18:06+0100 itho/cmd high
2021-11-03T10:19:04+0100 itho/ithostatus {"temp":0,"hum":0,"ppmw":0,"ReqFanspeed":6552.6,"Balance":0,"supply_fan_requested":3100,"supply_fan_actual":3093,"exhaust_fan_requested":3159,"exhaust_fan_actual":3173,"supplyTemp":15.85,"exhaustTemp":8.31,"status":0,"RoomTemp":15.85,"OutdoorTemp":8.31,"Valve_position":0,"Bypass_position":0,"Summercounter":0,"Summerday":0,"FrostTimer":0,"BoilTimer":177,"StartCounter":120,"CurPosition":0,"VKKswitch":0,"GroundHeatExchangerSwitch":0,"AirCounter":2615,"Global_fault_code":0,"Actual_Mode":3,"pir_fan_speed_level":-1,"Highest_received_CO2_value":592,"Highest_received_RH_value":239,"Air_Quality":100,"Remaining_override_timer":0,"Fallback_speed_timer":56,"Exhaust_Constant_Ca0":2}
2021-11-03T10:19:04+0100 itho/remotesinfo {"beneden":{"lastcmd":0,"co2":592},"boven":{"lastcmd":4,"co2":565}}
2021-11-03T10:19:04+0100 itho/lastcmd {"source":"MQTT API","command":"high","timestamp":1635931086}

In the shop, on the temp-sensor page is quoted:

Update: waarschijnlijk is het binnenkort mogelijk om via de firmware van de add-on ook de originele itho sensor betrouwbaar uit te lezen. Deze vervangende sensor is in dat scenario niet meer nodig.

Is this already the case, or do I have to replace the original sensor for the moment? Also, when this is not the case already, is there a ETA for this functionality?

Ik kan bevestigen dat bovenstaande fan niet compatible is 🤣
Geen aansluiting om de wifi addon te installeren.

When using v2.3-beta1 with the default settings on a CVE-S ECO, the software seems to read data from the built-in humidity/temperature sensor, which is nice. But the settings (System settings > Autodetect built-in humidity/temp sensor) don't appear to have changed since this was implemented, so it is unclear what the expected behaviour is.
Looking at the source code I think it requires syssht30 in the settings to be on to consider humidity sensor support active but as far as I can see it's off by default, so not sure why it does show sensor data then.

• Is the first setting, Hum/Temp sensor support, still needed, as it already seems to support it when it's off (default setting)?
• Is the first setting (as suggested by heading) only for the built-in sensor, as it controls the syssht30 setting for which the code seems to have implementations for an 'original' and 'alternative' sensor?
• The warnings about enabling the first option (reading) without enabling the second option (block support in Itho firmware) no longer apply if I've correctly read the discussions, so they can be removed.
• In MQTT settings, enabling Home Assistant MQTT Discovery only seems to send out a message for the fan even though humidity/temperature is exposed in the interface, API and MQTT sensor. If humidity/temperature is supposed to work without enabling any other settings, the discovery should probably also work without enabling any other settings? Or make it a setting to configure whether only the fan or also humidity/temperature messages are sent.

I think it's a good idea to track potential progress on this via a issue:

The add-on is able to control the itho box in standard or medium mode setting only. This means you can use the original remote but if you leave the itho box in low or high setting the itho won't accept commands from the add-on. This is itho designed behaviour.

Add MQTT topic to allow changing the speed to low/med/high as set in the web interface setting.
For example something like "itho/speed" and then (off,) low, med or high as values.
This also gives better integration with the Home Assistant Fan component.

After adding new remote the fan doesn't switch to low. In the GUI it shows as low but the fan is still at the previous setting

the websocket is not functioning properly on these versions, on iOS it seems totally unusable, on MacOS chrome seems to be working fine and after a few minutes Safari seems to get restored and functions properly until the next reload of the browser window.

Error message:
[Error] WebSocket connection to 'ws://nrg-itho-1234.local/ws' failed: The operation couldn’t be completed. (kNWErrorDomainPOSIX error 54 - Connection reset by peer)

Update:
https://developer.apple.com/forums/thread/685403
I found a message with the same error on the Apple forum, no solution yet

The board plugged into the Itho CVD-S Eco appears to work well. When plugged in I can log into its standard wifi SSID and set the SSID of my local network. The API by web is accessible on the local network. Switching on mqtt works, the current speed is reported as 20, both by mqtt and by rest call to the api.

However, the Itho is set on automatic mode (switch set to position 2). When detecting high humidity in the bathroom it automatically switches to a higher speed. However, this new speed is not picked up by the rest call, nor is it reported in the mqtt sensor (topic: itho/state). What could be the issue? Is it the humidity sensor which is blocking the updated info somehow?

Current firmware version: 2.3-beta4
Hardware revision: 2

When trying to reacht http://192.168.x.x/api.html I get the error "NOK"

When I interrupt the power from the fuse box, the device does not automatically connect to my wifi. I first have to connect to the Ithowifi module and then perform a restart from the web interface. Then it will work.

Latest firmware and HRU-350

Seems around position 34 the field labels and values no longer match and seem off by one.
itho status seems OK, the settings not.

best illustrated here:

Seems to start around index 35 but hoping you still have the HRU 350 yourself, is this something you can reproduce?

Please make the hostname/domain name editable,
mqtt hostname "generic" instead of itho/ itho/
and tls/username password option available (if not already)

Username/passwords for website (access), admin, and such changeable both,
it would be better to either upload a "config" file with all settings or .. a 1 time "wizard" that sets all options

• wifi SSID/AP
• username (custom) and custom pw (all access)
• checked "options" like checked boxes for "common" setup

• enable rf-join, temp/hum sensor etc

later-on config "details"

• max of 10 users each with all options to read / write certain functions

The reason to raise this issue is that defaults can lead to security issues, setting a custom username/password mitigates this issue a bit. uploading a custom config file makes it easy for testing (wiki on how to automate on detecting this default 1st setup is nice for home automation.

ps expose also via mqtt the firmware / and a checkbox for update is available check (x.x and 2.x )

I have put the Itho module into a CVD-S Eco roofventilator that has automatic sampling of CO2 and humidity. I put the ventilator on 2, which is automatic mode.
Through the module the API is accessible without any issues. Home Assistant reports the speedvalue without issue. However, the MQTT connection did not appear to work - the sensor did not exist in Home Assistant even though the API reports MQTT as "connected". I have four other MQTT devices and a broker running smoothly. So it is not a setup issue.
I later discovered the WIFI connection was not stable. After I fixed that, the problem appeared to be over.
This is just to report that this board works with CVD-S Eco roofventilator! Brilliant job

The Demandflow does not respond to any of the api calls given by the non-CVE wifi module

A request to any of the following gives OK:
/api.html?timer=1337
/api.html?command=timer1
/api.html?vremote=timer1
/api.html?vremote=timer2
/api.html?vremote=timer3

I would expect that on the status page 3_6_9-hours-demandflow-timer_sec would change and the Demandflow would turn on high.

NRG.Watch non cve wifi with cc1101 - HW rev: NON-CVE 1, FW ver.: 2.3.1
Itho DemandFlow - Itho device type: DemandFlow, Itho fw version: 21
Itho WTW HRU 350
Itho Remote 536-0146

According to the ITHO status page there should be individual MQTT topics per label: "itho/ithostatus/[label]".
In firmware version 2.3-beta2 the values on these topics no longer get updated. This used to work in the previous firmware that I used: 2.3-alpha9.
The only topics that do get updated according to the interval specified in the system settings are:
itho/remotesinfo
itho/lastcmd
itho/ithostatus
No topics under itho/ithostatus/ receive any updates.

I'm running firmware version 2.3-beta2
Update freq: 5 sec
MQTT settings: everything default, no Home Assistant or Domoticz features enabled.

When I enable the Domoticzc MQTT integration no topics under itho/ get updated (including the three mentioned above). The Domoticz integration however does work (messages to domoticz/in and from domoticz/out).

Today I received the temp/hum sensor and was planning to move my remote to the addon when I saw that the CC1101 wasn't working.
The steps I took:

• Installed beta 10, OK
• Turned on the HA discovery, OK
• Installed the temp/hum sensor, OK (thanks !)
• Added the addon as a virtual remote
• Turned on the activate the CC1101 RF module, NOK
  The logging shows Setup: init of CC1101 RF module failed

When I received the addon in the beginning I'm sure I checked this and at the time everything was OK.
When I look at the files on the file system the is a logfile without any extension which holds 5215 N: Setup: init of CC1101 RF module successful

Logfile from the debug page: logfile1.current.log

Module keeps disconnecting from Wi-Fi and gets Warning: I2C timeout's during the day. Have to hard-reset the module.

Current firmware version: 2.3-beta4
Hardware revision: 2

2021-11-16 20:32:29 N: Setup: SHT30 sensor not present 2021-11-16 20:32:29 N: Setup: init of CC1101 RF module successful 2021-11-16 20:32:30 N: Warning: I2C timeout 2021-11-16 20:32:31 N: MQTT: connected, System config: 1 2021-11-16 20:32:31 N: Webserver: started 2021-11-16 20:32:31 N: mDNS: started 2021-11-16 20:32:31 N: Hostname: nrg-itho-0e58 2021-11-16 20:32:31 N: Setup: done 2021-11-16 20:33:09 N: Error: Task SysControl timed out! 2021-11-16 20:33:17 N: System boot, last reset reason: SDIO_RESET 2021-11-16 20:33:17 N: HW rev: 2, FW ver.: 2.3-beta4 2021-11-16 20:33:20 N: WiFi: connection successful 2021-11-16 20:33:20 N: WiFi info: 2021-11-16 20:33:21 N: Mode:STA 2021-11-16 20:33:21 N: Status:3 2021-11-16 20:33:21 N: IP:192.168.2.65 2021-11-16 20:33:21 N: Setup: Virtual remote ID: 155,14,88 2021-11-16 20:33:25 N: Setup: SHT30 sensor not present 2021-11-16 20:33:25 N: Setup: init of CC1101 RF module successful 2021-11-16 20:33:26 N: Warning: I2C timeout 2021-11-16 20:33:26 N: MQTT: connected, System config: 1 2021-11-16 20:33:26 N: Webserver: started 2021-11-16 20:33:27 N: mDNS: started 2021-11-16 20:33:27 N: Hostname: nrg-itho-0e58 2021-11-16 20:33:27 N: Setup: done

Please let me know if there is more specific info needed.

Taken from tweakers.net to an issue here.

CVE ECO RTF SE
print received monday (22/2) including the RF component whichis enabled in the config (automatically), no remotes added yet.

MQTT details filled out but stays at 'disabled'.
Every 20-30 seconds a reboot of the device.
Debug page sometimes is completely blank when device is restarting obviously, shown is:
memory 187212 / free 179248

log:
`

Config version: 003

Itho I2C connection status: connected

File system: 17319 bytes used / 173441 bytes total

CC1101 task memory: 1956 bytes free
MQTT task memory: 0 bytes free
Web task memory: 5892 bytes free
Config and Log task memory: 5876 bytes free
SysControl task memory: 5828 bytes free

2021-02-24 16:34:05 N: System boot, last reset reason: SDIO_RESET
2021-02-24 16:34:08 N: WiFi: connection successful
2021-02-24 16:34:08 N: WiFi info:
2021-02-24 16:34:08 N: Mode:STA
2021-02-24 16:34:08 N: Status:3
2021-02-24 16:34:08 N: IP:192.168.178.41
2021-02-24 16:34:08 N: Setup: init of CC1101 RF module successful
2021-02-24 16:34:26 N: MQTT: connection failed, System config: on
2021-02-24 16:34:26 N: Webserver: started
2021-02-24 16:34:26 N: mDNS: started
2021-02-24 16:34:27 N: Hostname: nrg-itho-21a4
2021-02-24 16:34:27 N: Setup: done
2021-02-24 16:34:27 N: Error: Task MQTT timed out!
2021-02-24 16:34:34 N: System boot, last reset reason: SDIO_RESET
2021-02-24 16:34:37 N: WiFi: connection successful
2021-02-24 16:34:37 N: WiFi info:
2021-02-24 16:34:37 N: Mode:STA
2021-02-24 16:34:37 N: Status:3
2021-02-24 16:34:37 N: IP:192.168.178.41
2021-02-24 16:34:37 N: Setup: init of CC1101 RF module successful
2154 N: System boot, last reset reason: POWERON_RESET
5005 N: WiFi: connection successful
5093 N: WiFi info:
5112 N: Mode:STA
5130 N: Status:3
5149 N: IP:192.168.178.41
5250 N: Setup: init of CC1101 RF module successful
2021-02-24 16:35:02 N: MQTT: connection failed, System config: on
2021-02-24 16:35:02 N: Webserver: started
2021-02-24 16:35:02 N: mDNS: started
2021-02-24 16:35:02 N: Hostname: nrg-itho-21a4
2021-02-24 16:35:02 N: Setup: done
2021-02-24 16:35:03 N: Error: Task MQTT timed out!
`
MQTT details which are working on other device;
Status: disabled
MQTT active; ON
server: 192.168.178.037
user: abcd
pwd: abcd
port: 1883
state topic: itho/state
cmd topic: itho/cmd
Domotiqz: OFF

User and Password are replaced by abcd but are 4 char each in real life
the server address has the 0 automatically added in front of 37 in the last byte of the address.

If a temp/hum sensor is found, publish it's data to the webui.

I suggest adding it to the landing page/home page but also on the debug page.

Arjen - could you pls add the relevant tags? My version script depends on it ;)
these are missing:
92fdcb0 = 2.2-beta10
15bf20f = 2.2-beta9
c9e8eaf = 2.2-beta8
2f2d7bd = 2.2-beta7

For a HRU350 I would expect 4 -different- temperatures, inside in/out and outside in/out. 4 are shown but these seem to be the same value.

Hi,

I have change the Wifi SSID and it connects to Wifi(I can see DHCP lease) but the web interface is gone.
How can I reset or connect to it?

Add support for the Itho Remote 536-0146 buttons and functions on the NRG.Watch Non CVE WiFi Module.

Top left / Normal
1-12-2021 10:27:01: W 62 --,--,-- --,--,-- 52,5C,BB 22F8 3:00,01,02 (cmd:unknown)

Top right / Eco Comfort
1-12-2021 10:27:01: W 62 --,--,-- --,--,-- 52,5C,BB 22F8 3:00,01,02 (cmd:unknown)

Lower left / Cook
1-12-2021 10:27:42: W 65 --,--,-- --,--,-- 52,5C,BB 22F3 5:00,02,1E,02,03 (cmd:unknown)

Lower right / Timer 3 6 9
1-12-2021 10:28:24: W 71 --,--,-- --,--,-- 52,5C,BB 22F3 5:00,42,09,03,03 (cmd:unknown)
1-12-2021 10:28:24: W 70 --,--,-- --,--,-- 52,5C,BB 22F3 5:00,42,06,03,03 (cmd:unknown)
1-12-2021 10:28:24: W 69 --,--,-- --,--,-- 52,5C,BB 22F3 5:00,42,03,03,03 (cmd:unknown)

NRG.Watch non cve wifi with cc1101
Itho DemandFlow
Itho WTW HRU 350
Itho Remote 536-0146

I am running the latest 2.3-beta4 beta but it happened in the previous beta3 as well.
Hardware revision: 2

After a reset or the MQTT last 2 octets disappear. After reentering the config MQTT connects again.
e.g. 192.16 instead the full 192.168.x.x

PS.
2 feature requests
1- Reset thru MQTT/API to keep the config fresh.
2- If Domoticz is is used in MQTT keep the other MQTT topic as well. I know I can use node-red but an easy Domoticz topic is higher appreciated especially with the original MQTT topic for some other automation things

version: commit 6d3231a (tag: Version-2.3-beta3)
HW version: 2
unit: HRU 350

reproducer:

1. navigate to the addon's url in 2 separate browser sessions (opening browser console in both of them helps)
2. in 1 of the sessions, navigate to Itho settings and hit Retrieve settings
3. observe the websocket events never stop flowing in
4. get off your bed and go to reset your board manually

it looks like a forkbomb, where new ws connections are being spawned indefinitely, probably consuming all the memory so the sketch crashes.
Eventually, the board fails to reboot properly but that might be another bug.

I think as a new row is spawned, in 1 session, it replicates to other session as well together with a new ws connection, which is in turn being replicated in the first session, etc.,

Describe the bug
WebSocket connection is not established resulting in empty fields on the web page.

Desktop (please complete the following information):

• OS: [e.g. iOS] Windows 10 (only?)
• Browser [e.g. chrome, safari] Edge and Chrome
• Version [e.g. 22] not known

I am too lazy to make this a proper PR.

Problem
When making changes to the web interface page, some changes require a restart. The count down is less than a minute and so is using the 'restart device button'.
The page shows "This page will reload to the start page in 00:20 seconds".
This should be either " in 20 seconds" or "00:20 minutes".

var message = 'This page will reload to the start page in ' + min.toString() + ':' + sec + ' seconds...';

Upon checking the code, it seems secondsRemaining is always set to 20 it seems cleaner to just show "20 seconds" by removing min.toString() all together.

Small problem. I am having the non-CVE version.

The update page shows:

Current firmware version: 2.3-beta3
Hardware revision: NON-CVE 1
Latest firmware version: 2.3-beta2

button points to https://github.com/arjenhiemstra/ithowifi/raw/master/compiled_firmware_files/non-cve_rev_1/nrgitho-noncve-v2.3-beta3.bin

Upon checking the code, the data comes from https://raw.githubusercontent.com/arjenhiemstra/ithowifi/master/compiled_firmware_files/firmware.json has this:

"NON-CVE 1": {
"latest_fw":"2.3-beta2",
"link":"https://github.com/arjenhiemstra/ithowifi/raw/master/compiled_firmware_files/non-cve_rev_1/nrgitho-noncve-v2.3-beta3.bin"
}

So perhaps it's cleaner to have latest_fw referred to that in the link? E.g. https://github.com/arjenhiemstra/ithowifi/raw/master/compiled_firmware_files/non-cve_rev_1/nrgitho-noncve-{{latest_fw}}.bin so it avoids double maintenance for new releases.

Itho Daalderop also provides heat-pumps (water/water) which uses I2C communication as well similar to the HRU units.

Today the end-user can only control limited parameters (room temp, heating moment) but not read parameters. This is useful to get more information out of the device similar to what's used here: https://github.com/pommi/python-itho-wpu/tree/370209603b70a464821b8340ce9e07c4b6c08855

Why via this project if there are already solutions out there?

1. MQTT gives much more flexibility than storing it locally (in influx)
2. Soldering / Raspberry PI only adds complexity
3. Single PCB design for multiple devices made by Itho

I've created a simple script that reads the WPU database of Itho and converts it to a C++ header file to get a head start.
It's here: https://github.com/jasperslits/ithowifi/blob/master/wpu.h

I was only able to compile test it (create a .cpp file and include the header) but would this be of any help as I cannot functionally test it?

Happy to assist with testing and on GoT there are more volunteers if needed.

As discussed on Tweakers.net:

My Itho wifi addon v1.3 cannot connect (reliably) to my Unifi Wifi with firmware v2.0.9 and higher.
I use a separate IoT SSID, hidden or not hidden does not make a difference.
Also tested a different Wemos D1 Mini, with the same results.
Tested with 2 different Unifi AP's (AP-AC-Pro and Nano-HD), even with disabling one of them.
Closest AP is about 3m away.

What goes right:
Flash with 2.0.7 via web interface or USB. Enter Wifi details. Reset, done.
Unifi AP Logging with v2.0.7:

Mon Feb 22 16:47:23 2021 daemon.info hostapd: ra1: STA 48:3f:da:95:9e:eb IEEE 802.11: associated
Mon Feb 22 16:47:23 2021 user.info : wevent[2227]: wevent.ubnt_custom_event(): EVENT_STA_JOIN ra1: 48:3f:da:95:9e:eb / 14
Mon Feb 22 16:47:23 2021 kern.warn kernel: ra1: Send EAPOL-Key M1, DA=48:3f:da:95:9e:eb, SA=f6:92:bf:1b:9b:53, len=113
Mon Feb 22 16:47:23 2021 kern.warn kernel: ra1: Recv EAPOL-Key M2, DA=f6:92:bf:1b:9b:53, SA=48:3f:da:95:9e:eb, len=129
Mon Feb 22 16:47:23 2021 kern.warn kernel: ra1: Send EAPOL-Key M3, DA=48:3f:da:95:9e:eb, SA=f6:92:bf:1b:9b:53, len=169
Mon Feb 22 16:47:23 2021 kern.warn kernel: ra1: Recv EAPOL-Key M4, DA=f6:92:bf:1b:9b:53, SA=48:3f:da:95:9e:eb, len=107
Mon Feb 22 16:47:23 2021 daemon.info hostapd: ra1: STA 48:3f:da:95:9e:eb WPA: pairwise key handshake completed (RSN)
Mon Feb 22 16:47:25 2021 user.info : wevent[2227]: wevent.ubnt_custom_event(): EVENT_STA_IP ra1: 48:3f:da:95:9e:eb / 192.168.3.43
Mon Feb 22 16:47:33 2021 daemon.info hostapd: ra1: STA 48:3f:da:95:9e:eb RADIUS: starting accounting session 3B01848EC557C770
Mon Feb 22 16:47:33 2021 user.info : stahtd[2228]: [STA-TRACKER].stahtd_dump_event():{"message_type":"STA_ASSOC_TRACKER","ip_assign_type":"dhcp","wpa_auth_delta":"30000","mac":"48:3f:da:95:9e:eb","auth_ts":"346289.862188","vap":"ra1","assoc_status":"0","event_type":"success","ip_delta":"2320000","arp_reply_gw_seen":"yes","assoc_delta":"0","auth_delta":"0","event_id":"1"}

What does not work correctly:
With v2.0.9 and higher the addon does not always connect to Wifi.
Association fails and according to the Unifi AP the client leaves.
Then the addon starts its own AP, and I can connect to that fine.

Unifi logging with firmware hw1-v2.2-beta1-extra-wifi-log.bin

Mon Feb 22 16:41:53 2021 daemon.info hostapd: ra1: STA 48:3f:da:95:9e:eb IEEE 802.11: associated
Mon Feb 22 16:41:53 2021 user.info : wevent[2227]: wevent.ubnt_custom_event(): EVENT_STA_JOIN ra1: 48:3f:da:95:9e:eb / 14
Mon Feb 22 16:41:53 2021 kern.warn kernel: ra1: Send EAPOL-Key M1, DA=48:3f:da:95:9e:eb, SA=f6:92:bf:1b:9b:53, len=113
Mon Feb 22 16:41:54 2021 kern.warn kernel: ra1: Send EAPOL-Key M1, DA=48:3f:da:95:9e:eb, SA=f6:92:bf:1b:9b:53, len=113
Mon Feb 22 16:41:54 2021 kern.warn kernel: ra1: Recv EAPOL-Key M2, DA=f6:92:bf:1b:9b:53, SA=48:3f:da:95:9e:eb, len=129
Mon Feb 22 16:41:54 2021 kern.warn kernel: ra1: Send EAPOL-Key M3, DA=48:3f:da:95:9e:eb, SA=f6:92:bf:1b:9b:53, len=169
Mon Feb 22 16:41:54 2021 daemon.info hostapd: ra1: STA 48:3f:da:95:9e:eb WPA: pairwise key handshake completed (RSN)
Mon Feb 22 16:41:54 2021 kern.warn kernel: ra1: Recv EAPOL-Key M4, DA=f6:92:bf:1b:9b:53, SA=48:3f:da:95:9e:eb, len=107
Mon Feb 22 16:42:03 2021 user.info : stahtd[2228]: [STA-TRACKER].stahtd_dump_event():{"message_type":"STA_ASSOC_TRACKER","ip_assign_type":"roamed","wpa_auth_delta":"1050000","mac":"48:3f:da:95:9e:eb","auth_ts":"345959.964137","vap":"ra1","assoc_status":"0","event_type":"soft failure","assoc_delta":"0","auth_delta":"0","event_id":"1"}
Mon Feb 22 16:42:04 2021 daemon.info hostapd: ra1: STA 48:3f:da:95:9e:eb RADIUS: starting accounting session 059672CB94A6E3CB
Mon Feb 22 16:42:23 2021 daemon.info hostapd: ra1: STA 48:3f:da:95:9e:eb IEEE 802.11: disassociated
Mon Feb 22 16:42:23 2021 kern.warn kernel: Can't find pEntry(48:3f:da:95:9e:eb) in ApStaDel
Mon Feb 22 16:42:23 2021 user.info : wevent[2227]: wevent.ubnt_custom_event(): EVENT_STA_LEAVE ra1: 48:3f:da:95:9e:eb / 14
Mon Feb 22 16:42:23 2021 user.info : stahtd[2228]: [STA-TRACKER].stahtd_dump_event():
{"message_type":"STA_ASSOC_TRACKER","mac":"48:3f:da:95:9e:eb","assoc_status":"0","vap":"ra1","event_id":"1","event_type":"sta_leave"}

Extra wifi logging with hw1-v2.2-beta1-extra-wifi-log.bin

<br>2021-02-22 15:32:02 N: Reboot requested
      8563 N: System boot, last reset reason: Software/System restart
      8743 N: Setup: wifi config loaded successful
      8859 N: Connecting to wireless network...
1970-01-01 00:00:03 N: Waiting for wifi connection
1970-01-01 00:00:04 N: Waiting for wifi connection
1970-01-01 00:00:06 N: Waiting for wifi connection
1970-01-01 00:00:08 N: Waiting for wifi connection
1970-01-01 00:00:10 N: Waiting for wifi connection
1970-01-01 00:00:12 N: Waiting for wifi connection
1970-01-01 00:00:14 N: Waiting for wifi connection
1970-01-01 00:00:17 N: Waiting for wifi connection
1970-01-01 00:00:19 N: Waiting for wifi connection
1970-01-01 00:00:21 N: Waiting for wifi connection
1970-01-01 00:00:23 N: Waiting for wifi connection
1970-01-01 00:00:25 N: Waiting for wifi connection
1970-01-01 00:00:27 N: Waiting for wifi connection
1970-01-01 00:00:29 N: Waiting for wifi connection
1970-01-01 00:00:31 N: Waiting for wifi connection
1970-01-01 00:00:33 N: Waiting for wifi connection
1970-01-01 00:00:34 N: Couldn't connect to network :(
1970-01-01 00:00:35 N: wifi AP mode started
1970-01-01 00:00:35 N: Setup: AP mode active

Logfiles:
logfile0.current.log
logfile1.current.log

I have a HRU 350 with firmware v4 and a 'retrieve settings' command returns an error 'Message: Settings not available for this device or its firmware version'. Also status information doesn't return any useful results.

I was doing some checks against Wiki and documentation and wanted to see if there was anything in remotes.json

https://github.com/arjenhiemstra/ithowifi/tree/master/remotes (also available in wiki as https://github.com/arjenhiemstra/ithowifi/wiki/Remotes) refers to an /edit link to update remotes.json

Step to reproduce on latest beta (2.3-beta3) as per Wiki:

Go to: http://[nrg-itho-A1B2]/edit (username/pwd both admin)

Observed issues:

1. There is no prompt for credentials
   So I guess it's sufficient to change the Wiki as the prompt for File Editor only shows up if the "File Editor authentication" is set to "On" in "System Settings".
   But for the non-CVE the prompt still doesn't show but I couldnt tell from 09_init_code.ino where this is coming from and if systemConfig.syssec_edit is empty somehow..

2. No files are available in the left menu

Upon debugging, I noticed that it upon loading the page it calls /edit?edit=%2F/index.htm which returns a 404

3. "Refresh List" does not do anything (probably connected to the previous item)
   This calls edit?list=%F which returns [] with status code 200.

This shows up with MacOS 12 / Chrome and Windows / Chrome. I cannot test it with another browser.

This is obviously a low priority item.

During the upload of the firmware file the 'loading'/'waiting' thingy appears before the upload/upgrade is completed.

By not doing anyting the it disappears again after 5 seconds but the progressbars for the OTA are gone.
Doning nothing again and just waiting eventually shows the 'Done...' twice + the 'text ... reboot in 20 seconds'. The numbers are counting down.

The upgrade is successfull so the OTA process is continued and it seems to be a website/visual thing only.
I'm unable to reproduce this consistently. It looks like it happens in about 1/3 of every OTA.
Currently experience this with 2.2-beta8 builds but also had this with the 2.2-beta7 builds.

First of all, thank you for this awesome controller!

I can't seem to get MQTT working with Mosquitto 2.0.11 in Docker Compose on ARM64.

Mosquitto logs (controller IP is 192.168.1.111):

1625501614: mosquitto version 2.0.11 starting
1625501614: Config loaded from /mosquitto/config/mosquitto.conf.
1625501614: Opening ipv4 listen socket on port 1883.
1625501614: Opening ipv6 listen socket on port 1883.
1625501614: mosquitto version 2.0.11 running
1625501616: New connection from 192.168.1.111:63386 on port 1883.
1625501616: Client <unknown> disconnected due to protocol error.
1625501618: New connection from 192.168.1.41:6575 on port 1883.
1625501618: New client connected from 192.168.1.41:6575 as shellyswitch25-483FDA827188 (p2, c1, k60).
1625501620: New connection from 172.19.0.1:35916 on port 1883.
1625501620: New client connected from 172.19.0.1:35916 as 7FNNeLndNuWcyFsztiXyFE (p2, c1, k60).
1625501631: New connection from 192.168.1.111:63387 on port 1883.
1625501631: Client <unknown> disconnected due to protocol error.

Mosquitto config:

allow_anonymous true

listener 1883
protocol mqtt

Docker Compose file:

version: "3.4"
services:
  mosquitto:
    container_name: mosquitto
    image: eclipse-mosquitto:2.0.11
    ports:
      - "1883:1883"
    volumes:
      - ./configs/mosquitto/mosquitto.conf:/mosquitto/config/mosquitto.conf:ro
    restart: always

Itho WiFi controller firmware version is 2.2 and config:

{
    "sys_username": "admin",
    "sys_password": "admin",
    "syssec_web": 0,
    "syssec_api": 0,
    "syssec_edit": 0,
    "syssht30": 1,
    "itho_rf_support": 1,
    "rfInitOK": true,
    "mqtt_active": 1,
    "mqtt_serverName": "192.168.1.180",
    "mqtt_username": "",
    "mqtt_password": "",
    "mqtt_port": 1883,
    "mqtt_version": 1,
    "mqtt_state_topic": "",
    "mqtt_sensor_topic": "",
    "mqtt_state_retain": "yes",
    "mqtt_cmd_topic": "",
    "mqtt_lwt_topic": "",
    "mqtt_domoticz_active": 0,
    "mqtt_ha_active": 0,
    "mqtt_ha_topic": "homeassistant",
    "mqtt_idx": 0,
    "sensor_idx": 0,
    "itho_fallback": 0,
    "itho_low": 0,
    "itho_medium": 120,
    "itho_high": 220,
    "itho_timer1": 10,
    "itho_timer2": 20,
    "itho_timer3": 30,
    "itho_sendjoin": 0,
    "itho_forcemedium": 0,
    "itho_vremapi": 0,
    "itho_vremswap": 0,
    "nonQ_cmd_clearsQ": 1,
    "version_of_program": "004"
}

System log shows:

MQTT: connection failed, System config: 1

Home Assistant 4.6 and Shelly devices are able to connect.

The controller is also unable to connect with test.mosquitto.org at port 1883 or encrypted port 8883. Then also shows the error: MQTT Status Connection Timeout.

Any idea what's wrong?

I installed your latest hardware revision. And it works, until I use my remote. Than you cannot control the ITHO box. If I choose to restart the device via web gui, no effect. I have to physically power off and on the ITHO to make it work again.

Software 2.2-beta1 and later 2.1
ITHO: CVE ECO RFT SP
Control board: h60s40 E.CVERF-B-S_U2

      2210 N: System boot, last reset reason: POWERON_RESET
      3962 N: Setup: AP mode active
      3987 N: Webserver: started
      4008 N: mDNS: started
      4028 N: Hostname: nrg-itho-688c
      4048 N: Setup: done
      2154 N: System boot, last reset reason: TG0WDT_SYS_RESET
      3816 N: Setup: AP mode active
      3842 N: Webserver: started
      3864 N: mDNS: started
      3884 N: Hostname: nrg-itho-688c
      3904 N: Setup: done
    152728 N: Reboot requested
      2154 N: System boot, last reset reason: SDIO_RESET
      6612 N: WiFi: connection successful
      6631 N: WiFi info:
      6650 N: Mode:STA
      6669 N: Status:3
      6687 N: IP:10.0.0.154
      6713 N: Webserver: started
      6734 N: mDNS: started
      6755 N: Hostname: nrg-itho-688c
2021-02-24 17:48:42 N: Setup: done
2021-02-24 17:52:23 N: Reboot requested
2021-02-24 17:52:26 N: System boot, last reset reason: SDIO_RESET
2021-02-24 17:52:28 N: WiFi: connection successful
2021-02-24 17:52:28 N: WiFi info:
2021-02-24 17:52:28 N: Mode:STA
2021-02-24 17:52:28 N: Status:3
2021-02-24 17:52:28 N: IP:10.0.0.154
2021-02-24 17:52:28 N: Webserver: started
2021-02-24 17:52:28 N: Setup: init of CC1101 RF module successful
2021-02-24 17:52:28 N: mDNS: started
2021-02-24 17:52:28 N: Failed to deserialize remotes config json
2021-02-24 17:52:28 N: Hostname: nrg-itho-688c
2021-02-24 17:52:28 N: Setup: done
      2156 N: System boot, last reset reason: TG0WDT_SYS_RESET
      4612 N: WiFi: connection successful
      4631 N: WiFi info:
      4651 N: Mode:STA
      4669 N: Status:3
      4687 N: IP:10.0.0.154
      4715 N: Webserver: started
      4735 N: Setup: init of CC1101 RF module successful
2021-02-24 18:14:34 N: mDNS: started
2021-02-24 18:14:34 N: Hostname: nrg-itho-688c
2021-02-24 18:14:34 N: Setup: done
2021-02-25 00:14:29 N: Mem free: 182172, Mem low: 128828, Mem block: 97392
2021-02-25 06:14:29 N: Mem free: 182176, Mem low: 128828, Mem block: 97392
2021-02-25 07:17:10 N: Reboot requested
2021-02-25 06:52:35 N: System boot, last reset reason: SDIO_RESET
2021-02-25 06:52:37 N: WiFi: connection successful
2021-02-25 06:52:37 N: WiFi info:
2021-02-25 06:52:37 N: Mode:STA
2021-02-25 06:52:37 N: Status:3
2021-02-25 06:52:37 N: IP:10.0.0.154
2021-02-25 07:17:16 N: Setup: init of CC1101 RF module successful
2021-02-25 07:17:17 N: MQTT: connected, System config: on
2021-02-25 07:17:17 N: Webserver: started
2021-02-25 07:17:17 N: mDNS: started
2021-02-25 07:17:17 N: Hostname: nrg-itho-688c
2021-02-25 07:17:17 N: Setup: done
2021-02-25 07:29:33 N: Firmware update: NRG_itho_wifi_HW2x_FW2.1.bin
2021-02-25 07:29:50 N: Reboot requested
2021-02-25 07:29:55 N: System boot, last reset reason: 6
2021-02-25 07:29:55 N: WiFi: connection successful
2021-02-25 07:29:55 N: WiFi info:
2021-02-25 07:29:55 N: Mode:STA
2021-02-25 07:29:55 N: Status:3
2021-02-25 07:29:55 N: IP:10.0.0.154
2021-02-25 07:29:57 N: MQTT: connected, System config: on
2021-02-25 07:29:57 N: Webserver: started
2021-02-25 07:29:57 N: mDNS: started
2021-02-25 07:29:57 N: Hostname: nrg-itho-688c
2021-02-25 07:29:57 N: Setup: done
2021-02-25 07:29:57 N: Setup: init of CC1101 RF module successful
      4313 N: System boot, last reset reason: 7
      4332 N: WiFi: connection successful
      4351 N: WiFi info:
      4370 N: Mode:STA
      4389 N: Status:3
      4408 N: IP:10.0.0.154
      4443 N: MQTT: connected, System config: on
      4468 N: Webserver: started
      4488 N: mDNS: started
      4507 N: Hostname: nrg-itho-688c
      4528 N: Setup: done

The logs aren't telling me much, I hope you see something more 👍

At my Home Assistant instance I do get these warning messages during the restart:-

2021-05-18 22:17:49 WARNING (MainThread) [homeassistant.components.mqtt.fan] The 'payload_high_speed' option is deprecated, please remove it from your configuration
2021-05-18 22:17:49 WARNING (MainThread) [homeassistant.components.mqtt.fan] The 'payload_low_speed' option is deprecated, please remove it from your configuration
2021-05-18 22:17:49 WARNING (MainThread) [homeassistant.components.mqtt.fan] The 'payload_medium_speed' option is deprecated, please remove it from your configuration
2021-05-18 22:17:49 WARNING (MainThread) [homeassistant.components.mqtt.fan] The 'speed_command_topic' option is deprecated, please remove it from your configuration
2021-05-18 22:17:49 WARNING (MainThread) [homeassistant.components.mqtt.fan] The 'speed_state_topic' option is deprecated, please remove it from your configuration

The discovery payload that HA gets from the MQTT topic lists the mentioned options:

{
  "device": {
    "identifiers": "nrg-itho-e930",
    "manufacturer": "Arjen Hiemstra",
    "model": "ITHO Wifi Add-on",
    "name": "ITHO-WIFI(nrg-itho-e930)",
    "sw_version": "HW: v2, FW: 2.2"
  },
  "availability_topic": "itho/lwt",
  "unique_id": "nrg-itho-e930_fan",
  "name": "nrg-itho-e930_fan",
  "state_topic": "itho/lwt",
  "state_value_template": "{% if value == 'online' %}ON{% else %}OFF{% endif %}",
  "json_attributes_topic": "itho/sensor",
  "command_topic": "itho/cmd/not_used/but_needed_for_HA",
  "speed_command_topic": "itho/cmd",
  "speed_state_topic": "itho/state",
  "payload_high_speed": 220,
  "payload_medium_speed": 120,
  "payload_low_speed": 20,
  "platform": "mqtt"
}

Quick research shows that in the release notes of HA 2021.4 at the "MQTT Fan" options are mentioned in the breaking change section and the support of the used options will likely be removed at HA 2021.7.0 release.

I'm not familiar with this codebase to quickly submit a PR to get this fixed without breaking the discovery for older (< 2021.4) HA versions.
Despite the warnings the addon works ok. Many thanks for that !

Just for the record a few details of my setup:

• ITHO Addon firmware: 2.2
• Hardware revision: 2
• Home Assistant version: 2021.5.4

Frank

Looks like i've found an issue when an add-on module is used with a wifi mesh network.

When the module first starts with its own AP network everything works fine, even connects to specified Wi-Fi after a soft restart from WebUI.

However, after hard restart (pulling MV plug from the outlet) it never connects to the configured WiFi network.
Wi-Fi LED never flashes.

Only rebooting into fail-safe mode helps.

I've tried it with a regular (non-Mesh) wifi network, and it works fine.

I think it gets confused when several different APs respond to the same SSID.

Firmware version: 2.1.2

I have multiple Itho CVE-S mechanical ventilation units. One of them is an Optima variant - CVE-S Optima IN type 03-00421, which has the CO2 and RV (relative humidity) sensor integrated.

The solution provided by Itho Daalderop is almost exactly like your IthoWifi hardware module.

Is there a way/could we think of a way to implement/integrate/circumvent the existing Itho Daalderop sensor module with your module? Possibly extend or split the available 8-pin of the base board?

PS. I do not mind to alter/replace the current sensor. I was planning to extend the available sensors to a particle matter sensor, temperature/pressure, detect smoke (fire) and various other air quality sensors in addition to the CO2/Relative humidity. Home automation software in that respect is essential. Home-Assistant (in my case) is paramount to send alerts, status updates, etc..

See also the supplied images.