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.
