Support for HRU ECO-fan 3 BVF about ithowifi HOT 9 CLOSED

Have you tried a different cable? Use a high quality cable that is as short as possible would be my advise (Cat6 or better, 15cm rather than lets say 30cm)

from ithowifi.

Yes I tried different cables. Same result. I also tried the following:

• Upgrading to to 2.4.4. beta 6 --> same problem
• Downgrading to 2.4.2 --> same problem
• Downgrading to 2.4.1 --> Succes. No direct reset. But if I power-on/off the ITHO with the addon connected resets are starting again. Connecting the addon 20 - 30 secs after power-on is succesful. In the debug log the following message is shown

2336 I: System boot, last reset reason: RTCWDT_SYS_RESET
2570 I: HW rev: NON-CVE 1, FW ver.: 2.4.1
2249 I: System boot, last reset reason: POWERON_RESET
2421 I: HW rev: NON-CVE 1, FW ver.: 2.4.1
2283 I: System boot, last reset reason: RTCWDT_SYS_RESET
2466 I: HW rev: NON-CVE 1, FW ver.: 2.4.1
2319 I: System boot, last reset reason: POWERON_RESET
2556 I: HW rev: NON-CVE 1, FW ver.: 2.4.1
4975 I: WiFi: connection successful
5193 I: WiFi info:
5502 I: Mode:STA
5635 I: Status:WL_CONNECTED
5778 I: IP:192.168.0.127
5926 I: Setup: Virtual remotes, start ID: DF,EA,E0 - No.: 1
6142 I: Setup: remotes configfile loaded
6339 I: Setup: init of CC1101 RF module successful
6612 I: Setup: remotes configfile loaded
9338 I: MQTT: connection failed, System config: 1
9562 I: Webserver: started
9920 I: mDNS: started
10077 I: Hostname: nrg-itho-eae0
10262 I: Setup: done
2023-01-25 20:24:36 I: I2C init: QueryDevicetype - fw:4 hw:3
2023-01-25 20:24:36 I: I2C init: QueryStatusFormat - items:19
2023-01-25 20:24:36 I: I2C init: QueryStatus
2023-01-25 20:24:37 I: I2C init: Virtual remote join command send

I can reed status & info but there is no way I can get the virtual remote working. Pushing the buttons on webpage or on virtual remote page do not work. I do get MQTT commands like eg
{"source":"јb interface-vrem��� ��?\b��?nA?qј","command":"high","timestamp":1674680407}

Also using the api is unsuccesful (although page shows ok). Eg commands like the following do not work: http://192.168.0.127/api.html?command=high

Also no reaction in the debug screen on the RF remote. It is an older model pn on box (536-100).

Not sure what is going on but there are some problems.....Hope you can give some insight...

PS: I have another CC1101 RF on a wemos module with some code I found on the internet (running for the last 3-4 years). That one is sending commands that are working. If needed I can share....I might help in finding correct codes for the ITHO unit (if they are different...)

from ithowifi.

Thank for all the info!!

So it's probably not the cable since fw version 2.4.1 is kinda working...

"{"source":"јb interface-vrem��� ��?\b��?nA?qј","command":"high","timestamp":1674680407}"

The strange characters you see here are the result of a bug that is in fw version 2.4.1 and got fixed later (basically it points to a piece of memory that officially not longer is there). In some cases this could lead to a crash.

Looking at the log, the devicetype is readable. That's good news. The hardware / firmware version is known and supported by the firmware (all fw versions you tried should support it) so that shouldn't be the issue I expect.

If you happen to have a possibility to hook the module up to a computer using the USB interface and run a serial monitor to capture the serial logging created when the module crashes that might greatly help to find the source of the issue.

Not sure about the remote. The code in the firmware supports the newer kind of remotes using the honeywell protocol. The CC1101 RF on a wemos module you mention probably uses a predecessor of the library I'm using for the add-on firmware. I've rewritten part of the original lib to make it possible to use different remote ID's and other things.
The people who originally created the lib had also included (probably without knowing) the older itho protocol. All newer versions in use of this lib dropped support for that. I'm still searching for an older type remote to see if I can reverse engineer the protocol. If you could post a link to the version of software you are using on the wemos, that might be of some help in general.

Not sure of what type the 536-100 is (could you post a picture?) and if your HRU support the older and/or the newer protocol.
If it only supports the older one, that will explain why the virtual remote won't join / work. But the fact that the add-on is able to readout the itho firmware version etc. confirms that (at least a part of) the newer honeywell protocol is present but I'm not sure if the remote part is there as well.

It might not be a bad idea to first try to unpair the virtual remote by sending a leave command, wait a bit and send a join again. If the virtual remote is not paired correctly (or inadvertently joined with a different remote type set) the virtual remote will also not work. For a HRY of that era it's I think best to use the RFT CVE type as that one seems to be around longest.

from ithowifi.

Ok, I believe the resets are related to a power issue. With an usb adapter connected to the addon there are no crashes anymore (not sure if this can cause any damage to the ITHO unit).

I have now sw ver 2.4.3 running but cannot get the virtual remote working. After a reboot of the ITHO unit I tried the leave command on the virtual remote page and would expect ALL remotes including the RF ones to leave. That wasn't the case as the RF remotes kept working. Than I unjoined directly with the ITHO remote (which unjoined all RF remotes) and tried joining again. The RF remotes joined but I don't know if the virtual ones joined (I increased the number virtual remotes to 2). Below is the log.

2249 I: System boot, last reset reason: RTCWDT_SYS_RESET
2360 I: HW rev: NON-CVE 1, FW ver.: 2.4.3
2292 I: System boot, last reset reason: POWERON_RESET
2447 I: HW rev: NON-CVE 1, FW ver.: 2.4.3
8611 I: WiFi: connection successful
8722 I: WiFi info:
8862 I: SSID:ASUS | BSSID[E4:F4:C6:1A:04:4B]
9034 I: RSSI:-49dBm
9230 I: Mode:STA
9527 I: Status:WL_CONNECTED
9657 I: IP:192.168.0.127
9827 I: Setup: Virtual remotes, start ID: DF,EA,E0 - No.: 2
10103 I: Setup: remotes configfile loaded
10334 I: Setup: init of CC1101 RF module successful
10742 I: MQTT: connected, System config: 1
11135 I: Setup: remotes configfile loaded
11275 I: Webserver: started
11401 I: mDNS: started
11530 I: Hostname: nrg-itho-eae0
11670 I: Setup: done
15230 I: I2C init: QueryDevicetype - fw:4 hw:3
15569 I: I2C init: QueryStatusFormat - items:19
15924 I: I2C init: QueryStatus
16115 I: I2C init: Virtual remote join command send

Not sure what to do to get the virtual remote working......Is there a way see if the virtual remote has joined at all? As the leaving command on the webpage doesn't seem to work maybe the joining command also doesn't work.

The other WEMOS based remote does work and also shows up in the debug RF menu. The setting to high shows eg the following

26-1-2023 20:46:21: _W 159 --,--,-- --,--,-- 0A,57,51 22F1 3:00,04,04 (cmd:high)

The code I am using for that one is
IthoEcoFanRFTvWebserver.zip

The original remote doesn't show-up in the debug RF menu. See below pictures

Would be great if we could get than one and the virtual remote working........

from ithowifi.

Ok, after reading other topics it seems that the physcial remote I have doesn't work with the addon (ancient / other RF protocal). Probably need to buy another newer remote.

Would still like to get the virtual remote working. I have tried copying the ID of the compatible WEMOS remote in the virtual remote setting. As it is already joined I hope it would work but unfortunatly it didn't.

I loaded Beta 6 and with the I2C sniffer I does seem to sent a command (with 0A,57,51 being the remote ID). I pressed the same "high" command twice and below is the outcome

28-1-2023 08:56:20: [82,80,24,01,04,00,
28-1-2023 08:56:20: [82,60,C1,01,01,11,00,12,C4,EB,16,0A,57,51,2E,22,F1,03,00,04,04,F0,00,
28-1-2023 08:56:14: [82,60,C1,01,01,11,00,12,C1,23,16,0A,57,51,2D,22,F1,03,00,04,04,F1,00,
28-1-2023 08:56:13: [82,80,31,D9,04,00,

Part of the command is similar (0A,57,51 22F1 3:00,04,04) to the RF command which does work.

26-1-2023 20:46:21: _W 159 --,--,-- --,--,-- 0A,57,51 22F1 3:00,04,04 (cmd:high)

Maybe this version of ITHO doesn't support remote commands via I2C. If that is true than the only option I see is not using I2C for remote commands but the addon's CC1101 . This obviously requires a SW change on the addon with an option to choose between I2C or RF for "virtual" remote control. Not sure how difficult that would be to implement (for me it is above my amateur coding skills)....

PS the addon now runs for more than a day with it own (external) power supply.....so I guess this should be ok?

from ithowifi.

Thanks for the link to the wemos firmware, this indeed uses the earlier version of the CC1101 lib for itho.
Looking at the code, this lib actually sends two commands; the old itho protocol and the newer honeywell protocol.
In the source code the old style commands can be found at: "rft message 1 commands"
The makers of the lib (and later editors like me) weren't are of the two protocol parts so the old one was removed.

Both are in the lib, so that is why you see the honeywell part on RF debug page.

I loaded Beta 6 and with the I2C sniffer I does seem to sent a command (with 0A,57,51 being the remote ID). I pressed the same "high" command twice and below is the outcome

What will be interesting now to see is wether a I2C message will be placed on the I2C bus if you press a button on your physical remote.

28-1-2023 08:56:14: [82,60,C1,01,01,11,00,12,C1,23,16,0A,57,51,2D,22,F1,03,00,04,04,F1,00,

This is a sign that the add-on firmware sends a command on the I2C bus, so that is working, but you itho firmware needs an older style command it seems. I'm actually not even sure if the older style command can be send through the i2c bus. That could mean that the only way you can control the HRU is through RF.

Maybe this version of ITHO doesn't support remote commands via I2C. If that is true than the only option I see is not using I2C for remote commands but the addon's CC1101 . This obviously requires a SW change on the addon with an option to choose between I2C or RF for "virtual" remote control.

True, the code from the wemos lib needs to be changes (it is now basically a copy of a raw RF stream that is not easy to adapt to different remote ID's). This what I did for the newer itho remotes but weren't able to do for the older itho remotes. Maybe the code from the wemos lib is enough to reverse engineer further, maybe I need a real remote to be able to do so.

PS the addon now runs for more than a day with it own (external) power supply.....so I guess this should be ok?

Yes, I think that is fine. Maybe your model doesn't deliver enough juice through it's RJ45 connecter to power a wifi add-on. The itho service tool is a simple serial bridge that requires maybe a few mAmps instead of the 200-400mA the add-on requres.

from ithowifi.

Oh and btw;

Probably need to buy another newer remote.

I think that won't make a difference. I suspect the newer remotes only send the newer signal (in that case I won't work with your HRU) or both the old and new signals. In that case it is just as good as your current remote.

from ithowifi.

Just checked, there is no actvitity on the I2C bus when pressing the buttons of the physical remote or the Wemos remote.

So if the Wemos library is sending old & new style commands than the addon probably picks-up the new style (in the debug window) but the ITHO reacts on the old style command.

So the virtual remote might work if we would be able to understand and could send the old style commands via I2C. However it might also not work as we don't know if Remote commands are accepted via the I2C bus.

Not sure if you are planning to investigate this further but if you do I am willing to test whatever you come with.

Thanks already for your support....can at least read all the status info now and I can still use the Wemos Remote for my home automation.....

from ithowifi.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from ithowifi.