Hi @kjeet90, I was really happy when i saw this app! 
I bought Modbus gen 3, controlboard and ebyte dtu 810. to upgrade my heru 130s.
Temporay connected toghether on the floor to test its connection,
“as my unit is not placed in a proper work area”.
After configuration it connected asap, and working.
When it is connected now it states sockat A connect and socket B is disconnect.
I’m just curious if it is the same on your configuration?
Do I need to configure socket B parameter as well?
If it works, you don’t need to do anything else 
I’ve not configured anything for socket B and that says disconnected with me as well. As long as Socket A is setup to TCP Server and the correct serial settings, you connect to the gateways IP and port (set on socket A) and you’re good to go 
Thank you, that sounds fantastic!
Then i’m good to go, let’s get to the dirty work and actually replace the parts 
Again, thank you for this brilliant app!
Thanks, I did switch the A and B, and there seems to be a small progress towards the goal.
Now I see the “Activity” led on the Waveshare flash slowly, I think, it did not indicate any activity.
However, the only indication I see in the VirCom application is still TX, no RX, and the Homey app still says Timeout 
I will continue to experiment with my settings, all of a sudden hopefully I will see something.
Do you know of a good troubleshooting guide I could use to troubleshoot the Heru interface itself. If I hook it up to a USB->Serial, what should I expect to see? It would be great to see the Heru actually transmitting data in the first place.
To my knowledge it will only answer Modbus RTU requests and not transmitt anything on its own, unfortunately.
Initially I had some trouble when testing with the Moxa converter mentioned in the first post, but I think I concluded that my problem was the wiring then.
I assume the multi host should be disabled, without knowing exactly what that is If you can set the protocol to nothing I guess that would also be something to try. To just start off as simple as possible.
It’s hard to be of any help without having a similar device myself to test with. I can however recommend the cheap Ebyte mentioned in this thread. It’s very simple in regards to configuration options, if you decide to move to a simpler device eventually.
Also in the Heru remote I can only specify the Baud Rate and Id. Again, is it safe to assume that the rest of the parameters are “default”: 8, None, 1?
Yes, the ID should be set to 1, I have actually hardcoded that, maybe I should make that configurable in the future.
As long as the baud rate matches what is set on the ventilation system (default 9600), the rest should be as mentioned in the first post: 8N1
I realised now, while just by mistake keeping the Heru device open in the Web UI, that it reports 2 different errors. It Swithches between Timeout and “Port not open” every 15 seconds or so.
I don’t know if it is useful, but I have uploaded a new Diagnostics Report: c88a22e8-916c-4f9d-b5b3-280b107cf93e
It will reconnect if it has more than 5 unsuccessfull Modbus requests in a row. Then it destroys it’s connection and reconnects, that is why you get “Port not open”, because the connection is closed.
The “Modbus timeout” is set if there hasn’t been a reply to the modbus request after 1 second, and it needs to be connected to the gateway before it’s trying to send a Modbus request, so you are connecting to the gateway successfully. So the problem is between the Waveshare and the Heru unit.
Now, tonight I have hade some progress:
The Heru app can now connect fine, but it does not seem to retrieve any data. Or at least it does not show any data:
Bare in mind that I do not really know my ways around this, but I was able to cut&paste a python script that will talk to the device:
from pyModbusTCP.client import ModbusClient
# TCP auto connect on first modbus request
c = ModbusClient(host="192.168.1.5", port=502, unit_id=1, auto_open=True)
regs = c.read_holding_registers(3, 3)
if regs:
print(regs)
else:
print("read error")
Running this script I am able to retrieve values from the Heru, but I am still lacking the still to understand how to actually address the different registers.
Eg, what does the first 3 (in 3,3) mean, and how do I actually use the registers found in the documentation.
The 3, 3 return the following values, but again, I do not understand what they represent:
[60, 40, 66]
I have uploaded just another Diagnostic Report: 7c72feef-272e-4b3f-9c56-212283008b84
I do hope this will give you the juicy details that might be needed.
Based on the diagnostics report it’s still the same, just that the application were unable to set the device unavailable for some reason. I’ll have to look into that. As you can see below it still got a modbus timeout just before it failed to set the device unavailable, so that’s why you see the device as “connected”. But the dash instead of values on the capabilites indicates that they have never gotten a valid value.
2023-05-03T22:17:34.073Z [err] [ManagerDrivers] [Driver:gen-3-remote] [Device:2e772637-7854-40e1-a78a-22b5b4ff558c] Modbus timeout
2023-05-03T22:17:34.076Z [err] [ManagerDrivers] [Driver:gen-3-remote] [Device:2e772637-7854-40e1-a78a-22b5b4ff558c] Failed to set unavailable: Error: Not Found: Device with ID 2e772637-7854-40e1-a78a-22b5b4ff558c
The script you have used seems to use ModbusTCP, so I assume you have enabled a setting in your Waveshare that converts from RTU to TCP?
What you can try (just as a test) is to add a IQC Touch device and having the TCP/IP setting enabled to see if you get some values then. They don’t use exactly the same registers, but quite a lot are common.
EDIT: On a second thought, this will probably not work. The connection will still query in Modbus RTU. But you’ve confirmed your wiring is correct, you just need to turn off any convertion of the Modbus in your gateway.
Without having read any documentation about the library you have used I am assuming it means start reading from register 3 and read the total of 3 registers, meaning you would read fan speed settings shown in the image below (60%, 40% and 66%).
Thanks for your patience!
I’m continuing down my trial and error path:
Tonight I changed the Trasfer Protocol from Modbus_TCP to REAL_COM.
Now I do see both TX and RX traffic initated y the Heru app , but instead of Timeout in the Heru app, I am now seeing CRC Error combined with "Port Not Open.
Not sure what is my next step now, but maybe you understand what is going on?
I have uploaded another Diagnostics report: de392602-2b62-41c2-9de5-9002137b28dc
You shouldn’t convert any protocol through the gateway, it should only be there to convert from ethernet to serial, so you shouldn’t use the REAL_COM protcol, but use None instead. From Waveshare site:
An now we have arrived in something that seems to be working, sort of.
I am now able to read the values from Heru👍
But at the same time I am not able to modify the settings of the Heru.
If I change the Temperature, or the Fan Mode in the app, it does not update the Heru.
Also:
There seems to be an issue in the IOS Mobile app. I’m using the latest Beta together with my 2123 Pro:
When I open the “Display page” with all the values listed (tab #3), it gives the following error:
RangeError: Maximum call stack size exceeded
Given the error message, I suspected that there might be too many “info blocks” shown in the page, and I limited to 6 or so, but I still get the same error.
Replying to myself:
Actually the problem seems different:
I still see a behaviour where the app seems to switch between working fine, and recieving a timeout.
After resorting the app, I receive updates, and I am actually able to write updates to the Heru👍
I just realised that when I was not able to write, I was also not receiving updates, and the App had probably died on me.
After a restart I see the behaviour of working/timeout again.
It actually has nothing to do with a limit, it is when a custom Alarm capability is on, and then you are opening that device in the new mobile app, which usually opens on the page the alarm is displayed on which causes it.
It is known issue for a few weeks now, but has yet to be fixed by Athom, please do send in a message to Athom’s (early access) support link so it gets higher on their priority list.
Good that the communication is working-ish now Weird that you get a timeout, haven’t heard about this issue from anyone else, and I assume the control card for the Heru should be mostly the same between units. One second should be more than enough to get a response from the Heru. Do you maybe have some setting on your gateway that could possibly cause this? Some timeout or another setting somewhere? I can probably make the modbus timeout configurable, but unfortunately I don’t have much time the next few days to look into this.
Kjetil, for now I can manage this, so do not feel that this is something that needs be adressed right now.
When you have the time, could I also ask if it will be possible to configure more different Status Indicators?
Personally I thing it would be great to be able to select any of the temperatures. Or at least Outdoor/Supply.
I have looked into the Waweshare settings once more and the only timeouts that can be defined are related to Multi-Host. If multicast are not enabled, these are not in play.
Since the device class is thermostat it’s unfortunately not possible to change the status indicators. You will see the target temperature and know if the measured is above/below/on target by the blue/red/black circle. Maybe this is something that Athom will change eventually, but as of now it’s not possible 
Hi! I’m super-excited to see this app. Been looking for something like this since I moved into my new house two years ago.
I tried adding an IQC Touch device, and I have a Heru 200T (next-gen I’ve seen been used to describe the type of 200T). I have hooked the unit up via RJ45, and I have the Heru app on my phone. It’s fully functional, and I can see a “Martinsson Elektronik” on the IP address on my router.
I have a Homey Pro 2023 on the same VLAN and subnet. The address responds to ping. Still, when the device is set up, I get “device unavailable”. I’ll try removing the pairing to the app. Is there anything else I should look into?
