[APP][Pro] Modbus

[bischowski]

Hi Ronny,

reading DiscreteInput is not working.

i changed

                case 'BOOL':
                    valueBoolean = res[0];
                    break;

to

                case 'BOOL':
                    valueBoolean = res.response.body.valuesAsArray[0] == 1;
                    break;

in device.js and at least for my usecase (reading digital inputs of Siemens LOGO!) it’s fine now.

also changed from

this.log("Response: String: ", valueString, ", Number: ", valueNumeric);

to

this.log("Response: String: ", valueString, ", Number: ", valueNumeric, ", Boolean: ", valueBoolean);

[RonnyW]

Hi,
thanks for the hint. It seems I never adaptedt the old example with a real coding

I took over your coding (just changed the bool check into !=0).
A new test version is ready. You can try if it’s ok now.

[Valentin_Ciopei]

Hello,

Starting with last updates I’m getting some errors from time to time “rejecting because of earlier OutOfSync error”

The app still works and after a retry the value is correct.

Maybe this helps finding the issue: 91e53736-640f-4052-a98c-3afa42ca4b0f

I’m using the test version 0.9.2

[RonnyW]

Based on the log it seems you send 3 or 4 requests at the same time. Perhaps the Modbus device can’t process the calls in correct order.
If you have flows in parallel, try to call the flow actions in sequence, if needed with a 1sec delay and check it this solves the issue.

[Rmb]

@RonnyW

Create a flow and use the dvice flow actions to read a register.

Although I managed to create a normal flow, I should use advanced flows?
As I am unable to get the tag with the result.

[Valentin_Ciopei]

@RonnyW

Based on the log it seems you send 3 or 4 requests at the same time. Perhaps the Modbus device can’t process the calls in correct order.
If you have flows in parallel, try to call the flow actions in sequence, if needed with a 1sec delay and check it this solves the issue.

You are right!
I had a few flows set to “every X hours” or “every Y minutes”. Probably they conflicted from time to time. I added some random delays and it looks ok now.

thanks!

[Rmb]

Yes it requires advanced flows. I just did not know I had this feature.

[Rmb]

I like your solution and want to use it for NIBE SMO S40.
Could you give a clue how to get multiple text and values in the tile?
And maybe make the heat pump icon available?

[RonnyW]

@Rmb

Yes it requires advanced flows. I

Yes. with advanced flow you can process a flow card and await the result you get back as a token that you can use in following cards (write to virtual devices …).
In a standard flow, you can only process a flow action (fire and forget) without being able to get a result back.

[RonnyW]

You can create ab advanced flow.
Then insert the time trigger card.
Then insert the Modbus action cards one after another connected in line.
This way, the second cards starts after the previous one is completed.

[CaptainVoni]

Sorry, I’m a bit low on time lately. I answered your question in the other thread.

[Rmb]

@CaptainVoni

I have multiple registers with a documented size of 6

Did you eventually manage to read these registers with size 6?
I have a NIBE SMO-S40 with several registers of size 6 like

Hot water, compressor only MODBUS_INPUT_REGISTER 1583 10 kWh 6 0 9999999 0]

I can read it with size 4, but it shows the same value all the time, with very little variations.
Maybe I can try to read 1582, 1583 and 1584 with size 1 as bytes, and see how the behave during some time.

[CaptainVoni]

@Rmb

Did you eventually manage to read these registers with size 6?

Yes, I usually read them as “INT32-LE (16bit Word LE)”. I have no idea what the variable size mean, it just doesn’t make any sense.

@Rmb

I can read it with size 4

The “size” isn’t used for anything else than STRING and BYTE. For numbers it’s just ignored, i.e. it doesn’t make any difference whatever value you put there.

[Rmb]

It looks like NIBE counts the size in bytes (8 bits) en the Modbus app in 16 bits. Indeed in the Modbus app size only matters when reading bytes.
NIBE register 1489 (number of compressor starts) reads:
Size 4 registers shown in BYTES (so 64 bits) : 02 14 00 00 01 BD 00 00
INT16: 532
INT16-LE:5122
INT32-LE: 5122
INT32-LE (16 bit word LE): 532
UINT32/ACC32: 34865152
UINT32: 5122
UINT32-LE(16 bit word LE): 0

02 14 = 532
14 02 = 5122

and 34865152 = 02 14 00 00

So the value 01 BD is nowhere taken into account.
Trying to read UINT64 gives no response, not even an error, the card hangs.
As 64 bits can always be presented in UINT64, it might be that when reading 4 registers and presenting them in bytes, results in 4 times reading 1 register, as reading 4 registers and representing them as UINT64 results in 1 time 1 time reading 4 registers at once.
As I can also read 3 registers and present them in BYTES.

As the NIBE heatpump is operational for almost one year, I would expect the number of starts to be 150 days x 10 starts a day makes 1500.
It would be nice if I had some register with a well known value😉

Or wait for a compressor start and see the difference.

Edit: from the overlap of values, it looks that Nibes size 6 means 6 HEX characters? Like 0 2 1 4 0 0 ?

[CaptainVoni]

@Rmb

It looks like NIBE counts the size in bytes (8 bits)

My though also, but Modbus registers are always 16 bit wide. So a variable of size 5 would use two and a half registers. That doesn’t make much sense to me.

@Rmb

the Modbus app in 16 bits.

That’s how it should work in my opinion.

@Rmb

Size 4 registers shown in BYTES (so 64 bits) : 02 14 00 00 01 BD 00 00

In my opinion those are two separate values: 00 00 02 14 (reordered) and another 00 00 01 BD (reordered). I would use INT32-LE (16 bit word LE) to read that.

@Rmb

So the value 01 BD is nowhere taken into account.

Because it’s another value IMHO.

@Rmb

As the NIBE heatpump is operational for almost one year, I would expect the number of starts to be 150 days x 10 starts a day makes 1500.

That would be quite a lot of starts for just one year. During winter we average zero starts on our heat pump, because it never stops. During spring and autumn we have 2-3 starts each day, and in summer time exactly one (heating water). So my guess would be that 532 is the correct value for you.

[Rmb]

I think I understand, is a documentation failure from NIBE.
When I compare the files SMO40.CSV and SMOS.CSV I see the following values in the table size:

In the SMO 40 the biggest size is Signed or Unsigned 32. Signed is mostly used for temperature.
kWh in SMO 40 is UINT32, IN SMO-S40 size is 6.
The numbers 1…6 might just be a reference number to the s16…u8.

So I stick to the value 532, so INT32-LE (16 bit word LE).

@RonnyW That UINT32-LE(16 bit word LE) results in 0 must be a bug?

[RonnyW]

Sorry, had no time to check this.
I’ll check the code later if something is wrong with UINT32-LE.

Else you have still questions or did you get all the needed information from CaptainVoni?

[Rmb]

I am fine and now reading even more NIBE Registers .
As the number are not big yet, signed integers will do, so don’t hurry.

[Rmb]

@RonnyW appearently the IP-adres has changed of the SMO-S40.
Of course that ip-address shall be a fixed ip-address. As I am not on location, I tried to change the ip-address in the app, but when saving the new address it gives a time out on the old address and did not change. I restarted Homey, the app and thisabled the app, but no luck. Any ideas?

Edit: using the “Net Scan” app I see the new address, mailed to me, is also wrong. So no wonder I cannot change the ip-address. I have to be on site, or test 256 ip-addresses

Edit: I have been on location and the SMO-S40 has both WiFi and Ethernet, so two ip-adreses. So I switched of WiFi. Using the Homey app “Net Scan” shows the SMO is not available, but pingable. This is because “Net Scan” uses a different way to test availability. As @Adrian_Rockall explains at GitHub:

The app tries to connect to the device via the specified port. If the device connects or refuses the connection, the app reports the device is online. If there is no response, it reports it is offline.
Unfortunately, ping is a low-level system function that a Homey app doesn’t have access to.

The IPad app “Mtcp” also shows no response from the SMO-S40. I might have to restart that thing. But as it controls a heatpump, I want to be sure to know the right procedure.

So the problem of not being able to change the IP-address in the ModBus app is not a bug.

[RonnyW]

New test version 0.9.3:

• added a 10sec delay for auto reconnect to prevent crash caused by high CPU usage while trying to auto-reconnect. The app still tries to reconnect if that’s activated in device settings until the device is reachable again. Please make sure to use a static IP.
• added error handling for changed settings to prevent using a wrong IP adress.

@Rmb FYI. I added a delay to prevent the auto reconnect is using the whole CPU time. And settings view is using the old IP is the new is not recheable. So your IP issue was showing possible enhancements