ricott / homey-com.victronenergy

https://homey.app/a/com.victronenergy
GNU General Public License v3.0
3 stars 2 forks source link

Two GX registered in one Homey Pro (Early 2023) - VE bus errors - different behaviour of updating status values #16

Open ctec76 opened 1 year ago

ctec76 commented 1 year ago

Hi,

I got two Victron inverters with Cerbo GX in the same TCP LAN network because I am running two separate installations at my house.

Modbus-TCP is in both GX devices enabled, and I got the correct service unit IDs selected and registered in my Homey Pro (bus and battery, which is all I need). Basic TCP communication with both GX devices is perfect, i.e., no network issues as far as I can tell. Example: Both GX status pages open immediately in the web browser via IP address without any issues.

Registering both GX instances in my Homey is possible; i.e., registering both devices works fine. Homey Pro (Early 2023) Running the latest version of the Victron Homey app (v.1.1.6.).

I checked the device details with the Homey Developer Tools, and it confirms that only the first GX status values are updated every x seconds (only exception: Battery voltage). See screenshots. Note the values of the second one (every x minutes only).

The Homey app script reports the following error for the first GX (the one which reports updates every x seconds to Homey):

Error: Failed to read 'Switch Position (Mode)' (33) using unitId '227' (vebus)\n at modbusReading (/app/lib/victron.js:476:28)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async Promise.all (index 34)"

The second GX causes the following error in the Homey app script:

Failed to read 'Input power 3' (14) using unitId '227' (vebus)\n at modbusReading (/app/lib/victron.js:476:28)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async Promise.all (index 29)

The only differences regarding the Victron Cerbo hardware are:

This behaviour seems rather strange to me! Both devices can be communicated with via TCP without problems, and the GX portal has no issues whatsoever in reading the values.

If this is a problem with my configuration, I cannot say what that might be. To me, it rather seems to be a problem with the app. Can I provide more information to narrow down the source of this strange "value-update behaviour"?

Thanks in advance for any thoughts/feedback!

All the very best, Marc

Homey_main_gx

Homey_second_gx

ricott commented 9 months ago

Sorry for the slow response! I guess the problem has not solved itself?

I am aware of known problems with overlapping unit id's, for instance system use id 100 and battery also use id 100. This has caused problems in the past, which should be solved in the latest test version.

Code wise that app should support multiple GX devices. If it doesn't work what I would suspect is the jsmodbus package that the app use to do modbus that is at fault. Will see if I can test this scenario somehow.