Why? Are you using the development binding version?
Why? Have you any reason to think anything involved is using RTU over TCP?
You won’t fix this with random guesses.
No, but the Modbus protocol does.
It’s considered a broadcast. The rules say, that slaves may listen to messages addressed to id 0 but you must never respond.
It’s not uncommon for any given device to break the rules, but don’t expect it to work.
A few designs use id=0 as a sort of factory test tool or suchlike.
That’s good. So why not use the same settings in openHAB?
that it should work without a dongle.
In the same topic they are talking about MODBUS RTU serial connection. So I was hoping to be able to get the needed data without adding a dongle.
Is there maybe a way to bypass the MODBUS Binding limitation to be able to read the data as QModMaster does?
Modbus “broadcasts” (using id=0) have been considered before
In essence, you can make broadcasts to id=0 from the binding but may get warnings. (no response expected, of course)
I don’t think the changes needed to handle broadcasts warning-free have been put it place yet, but they would certainly stop you doing what you’re trying to do, use id=0 as ordinary read poll.
I see no reason to break the rules of Modbus protocol for everyone else in order to accommodate one person.
Put it another way, other people have made this device work with no such fiddling. I believe that has been done via connection to the RS-485 serial instead, though.
If your device modbus id=0 and cannot be changed, then it would be broken and useless. So we can figure out from that, that maybe the problem is that you haven’t found out how to change it…
I think you’re already well aware of this -
which seems to boil down to “you can’t change the id from 0 (on the onboard WiFi)”.
It’s quite possible that Huawei deliberately do this to discourage access this way.
Probably related to the onboard WiFi being in AP mode (own SSID) - how have you worked around that?
From what I can gather, the nnKTL-L1 series comes with an onboard WiFi, but it runs in AP mode (i.e. makes its own wifi network, not joining yours) for use with a proprietary app for setting up etc.
Because that’s a private network, Huawei can use any rules they like - which may be incompatible with a normal network where other systems may exist.
I have updated my tutorial with modbus TCP but you need the Huawei Smart Dongle-WLAN-FE with the latest update.Without a Dongle is possible if you have flashed your router with Tomato or DD wrt software.And make a bridge from the inverters wifi to your local network.
I have had a think about this, I’m sure that binding modification to deal with this case will mess things up for other people/systems using Modbus broadcast in the ordinary way. Basically, we can either expect responses or not, but not both.
Huawei need not care about that, because this part is supposed to be private to their products.
Having said all that, you’ve almost certainly got the un-fixed binding version which might well stumble through an exchange with id=0.
I wonder if you’re actually falling down at cross-domain issues, your test software is targetting a funny looking IP.
You’d have to be sure you can change the Modbus id for that to work , so that they are unique on the one wire, but I don’t think that is a problem for the serial interface side.
I’ve no experience, but would not have thought too difficult using libraries. You only need a gateway function, passing messages to some localhost port to and from the real IP, but with an id fiddle factor. Let the usual binding do the heavy lifting with decoding.
Retrofitting may or may not work. Pretty sure there are major framework changes from 3.0.2 to current development versions.
What are you hoping to gain here? An older version is more likely to work for you in this situation.
Sure, my point is what’s the IP of your host, are you trying to communicate cross-domain from openHAB?
Well in this imagined script that’s under your control. I would envisage something that simply accepts modbus messages from openHAB binding, substitutes id byte,passes out to network.
And, listens for messages from network for similar treatment before passing to openHAB.
However,now that I think of it, this might ruin any other modbus use you might want in future. I presume your Huawei target port cannot be adjusted, and is the standard port 502, so the script would have to grab that. Forcing the modbus binding to use non-standard port (which it can do) … but not all other devices allow port adjustment either.
I’ve tried to connect through USB-RS485 to the Inverter-Battery-PowerMeter Bus (COM port 3=485B2 and 4=485A2), but I don’t seem to get response from the inverter (set to modbus address 2) 0B=11 is the PowerMeter.
I didn’t try with openhab yet, i only tried with qmodmaster, as i don’t have the hardware to connect to openhab.
1 and 2 for my inverter is for cascading multiple inverters, should i connect through these port?
The power meter bus is intended to connect meters, where the inverter acts as Master and interrogates the meters. The inverter as Master is not going to respond to external interrogations from you.
In the other models there is a separate RS485 bus where the inverters role is Slave. Here you attach GSM gateway dongle etc. or indeed directly interrogate from openHAB.
That risks a clash as both dongle-gateway and openHAB want to Master and it won’t work (hence “remove the dongle” advice).
The supposition is that your model still has that RS485 bus but internally links it to a WiFi dongle.
EDIT - you’ve actually got multiple inverters, have you linked them (or intend to)?
No, i don’t want to link them, as they work on different POD, but i would like to read from them to openhab.
COM 1-2 is working with qmodmaster, thank you @rossko57 and @Rado1
So this could be an option, but i have to see if i can put them on the same bus or if they then try to work together …
I would also therefore prefer to use the MODBUS TCP connection, just (but this seems to be very complicated) have to get around the id=0 “limitation”.