Yes it can certainly be a misunderstanding on my behalf but since it is working flawless to read data I cannot understand what is going wrong when writing.
The ModBus RTU port is for my heatpump convectors are configured like this:
Which I read as to be 8 bits and not 16, but maybe I’m mixing bits and bytes here…
But when thinking about it again, it cannot really by single 8 bit words, it must be 2 x 8-bit words, as you suggested, otherwise the number space will be too small for the numbers I can read out.
As an example of what type of values I’m trying to read and write:
(Decimal values are multiplied by 10, so the number 16,5 would be read/written as 165.)
Good thinking about the LE/BE possibility but I tried to write with all the types available from the “Write Holding Register”-card but none of them works I’m afraid. The all give the same error code: “Encountered an unexpected error value: ‘[object Object]’”
I tried to create a diagnostics report: 4363fc10-3928-4af0-9ebf-8bf558158818
I hope we can solve this and again, thanks for all your effort with this app!
The log is showing a lot of connects/disconnects. You have set “single connect”, right?
But when the app tries to write the register, it get’s a “Req timed out” error.
The app uses the writeMultipleRegisters function to write a byte array. Do you have documentation what the converter is able to read/write? Perhaps it can only handle singe register updates?
The error you got is a bit irritating. I think the used module is returning an invalid error object (perhaps a string or JSON instead). I added additional error handlings in new test version 0.7.5 to get a valid message (hopefully).
Edit:
The converter or your RTU device supports functions 03 and 06 (read single/write single register).
The app uses 16 (write multiple registers) to use a generic write function where the amount of written registers depends on the data type.
I can only try to add a “write single register” action for 16bit data.
But I think your conclusion might be correct, since my RTU device only supports single registers!
Yes I’ve used Single connect but have now altered to Keep connection.
I’m afraid I cannot find any good spec on the converter regarding supported RTU functions, hopefully it supports them all but and my problem will be solved by a SingleRegisterWrite-action!
More info about the converter can be found here:
I just tried the new test version, 0.7.5, and the error log came out like this:
{“err”:“Timeout”,“message”:“Req timed out”,“request”:{“_id”:2,“_protocol”:0,“_length”:9,“_unitId”:2,“_body”:{“_fc”:16,“_address”:“203”,“_values”:{“type”:“Buffer”,“data”:[1,24]},“_byteCount”:8,“_numberOfBytes”:2,“_quantity”:1,“_valuesAsBuffer”:{“type”:“Buffer”,“data”:[1,24]},“_valuesAsArray”:[280]}}}
But my guess is that a new single register write-action will do the trick!
Hi @RonnyW. May I ask to add FLOAT32-LE to the write flow card? I have some registers in my inverter that are stored as FLOAT32-LE; I can read them without problems, but can’t write to them.
Splitted writing registers into single (16bit) and multi register action (>16bit)
If your are writing 16bit values (1 register), the “write single register” function is used (#06).
If you are writing longern values (>1 register), the “write multiple registers” function is used (#16).
So the writing goes through and when I read the same register I get the expected value, so your solution is correct. Great!
BUT unfortunately the writing action card also fails with the following error code:
“Cannot destructure property ‘bytes’ of ‘(intermediate value)’ as it is undefined.”
Hmm, strange.
I tried many different numbers, all as INT16, for instance; 0, 280, 120 and -120 and all of them were written correct since I could read the same values back from the device.
Could it be a return status value that is not returned or interpreted correct?
Exactly, it’s the returned Byte string that’s passed back as result token (the token you can use after teh flow card is finished).
I just wonder how this can be undefined.
I can write INT16 values without problems and I get the correct token.
Do you get the error every time or only for some values? Can you please send me a diagnostic report? I would like to check the log. Thanks
There are no error in your log. The result (byte string) is correct.
On my Homeys (19+23) all is working and the bytes string is returned as token.
Currently I have no idea why you get errors
I added an additional log line. Let’s try again with the new version. Please check and create a new report. You don’t need to post the ID. I get a mail with the log.
The app returns a valid token. The last log line is just before returning it to Homey.
Last idea…are you using AdvancedFlow od StandardFlow? I added this token to the action card but I think this will only work for AdvancedFlows. So if you already added this card before I released the update including the token, this could be a reason.
Hmm, yes it certainly looks correct. I have no idea why the card “fails” but since the actual writing works I happy with that.
I’m using an Advanced Flow for this.
But I just to try one more thing; I removed the app from Homey, restarted Homey and reinstalled the app and added the actioncards again, unfortunately with the same result as before…
Let me know if you want me to test something else, for now I’m totally happy with just ignoring that the card fails since the action itself is actually performed.
I will send you a donation for all your hard work, this is an extremely important and very awaited app! Thanks Ronny!
Hi again,
with help from robertklep (thanks again!) I think the flow action should work now without errors.
I think you used the slave device, right? I couldn’t see this in the logs because the modbus action is performed by the master device.
Can you please check the latest test version 0.7.9? Thanks.
But now I get an errorcode when trying to read registers instead.
The actioncard “Read Holding Register” now returns error: “registerType is not defined”
(I have used Type INT16, same as before, strange!)
I’m running the latest test version here (0.7.9) and can successfully access three different devices with different register types. If you provide some more information, it might be easier to track down any issues.
