Sequent 4rel4in v4 - Feeds for digital input errors

[brentk7]

I have a Sequent 4rel4in v4 card and have tried to configure the inputs to toggle service mode in njsPC. As soon as I enable the feed, I start getting errors in the log as shown below. I have tried using both inDigital1.value and plain inDigital1 as I am not sure what the difference is between them - but they both give the same error.

0|REM        | [28/06/2024, 13:25:50] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:4 {"isOn":0}
0|REM        | [28/06/2024, 13:25:50] info: [13:25:50] 192.168.20.230 PUT /state/device/i2c:1:1:4 {"isOn":0}
0|REM        | [28/06/2024, 13:25:50] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:4","typeId":1,"id":1,"params":["4"]}
0|REM        | [28/06/2024, 13:25:52] debug: 14 - Sequent 4rel4in v4 Executed read command 0x03 byte read:0x00
0|REM        | [28/06/2024, 13:25:52] debug: 14 - Sequent 4rel4in v4 Executed read command 0x00 byte read:0x01
0|REM        | [28/06/2024, 13:25:52] error: Error getting Sequent 4rel4in v4 digital input value for inDigital1.value
0|REM        | [28/06/2024, 13:25:52] error: Error getting Sequent 4rel4in v4 digital input value for inDigital2.value
0|REM        | [28/06/2024, 13:25:52] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:1 {"isOn":1,"latch":5000}
0|REM        | [28/06/2024, 13:25:52] info: [13:25:52] 192.168.20.230 PUT /state/device/i2c:1:1:1 {"isOn":1,"latch":5000}
0|REM        | [28/06/2024, 13:25:52] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:1","typeId":1,"id":1,"params":["1"]}
0|REM        | [28/06/2024, 13:25:52] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:2 {"isOn":0}
0|REM        | [28/06/2024, 13:25:52] info: [13:25:52] 192.168.20.230 PUT /state/device/i2c:1:1:2 {"isOn":0}
0|REM        | [28/06/2024, 13:25:52] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:2","typeId":1,"id":1,"params":["2"]}
0|REM        | [28/06/2024, 13:25:52] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:3 {"isOn":0}
0|REM        | [28/06/2024, 13:25:52] info: [13:25:52] 192.168.20.230 PUT /state/device/i2c:1:1:3 {"isOn":0}
0|REM        | [28/06/2024, 13:25:52] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:3","typeId":1,"id":1,"params":["3"]}
0|REM        | [28/06/2024, 13:25:52] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:4 {"isOn":0}
0|REM        | [28/06/2024, 13:25:52] info: [13:25:52] 192.168.20.230 PUT /state/device/i2c:1:1:4 {"isOn":0}
0|REM        | [28/06/2024, 13:25:52] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:4","typeId":1,"id":1,"params":["4"]}
0|REM        | [28/06/2024, 13:25:54] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:1 {"isOn":1,"latch":5000}
0|REM        | [28/06/2024, 13:25:54] info: [13:25:54] 192.168.20.230 PUT /state/device/i2c:1:1:1 {"isOn":1,"latch":5000}
0|REM        | [28/06/2024, 13:25:54] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:1","typeId":1,"id":1,"params":["1"]}
0|REM        | [28/06/2024, 13:25:54] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:2 {"isOn":0}
0|REM        | [28/06/2024, 13:25:54] info: [13:25:54] 192.168.20.230 PUT /state/device/i2c:1:1:2 {"isOn":0}
0|REM        | [28/06/2024, 13:25:54] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:2","typeId":1,"id":1,"params":["2"]}
0|REM        | [28/06/2024, 13:25:54] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:3 {"isOn":0}
0|REM        | [28/06/2024, 13:25:54] info: [13:25:54] 192.168.20.230 PUT /state/device/i2c:1:1:3 {"isOn":0}
0|REM        | [28/06/2024, 13:25:54] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:3","typeId":1,"id":1,"params":["3"]}
0|REM        | [28/06/2024, 13:25:54] verbose: 192.168.20.230 PUT /state/device/i2c:1:1:4 {"isOn":0}
0|REM        | [28/06/2024, 13:25:54] info: [13:25:54] 192.168.20.230 PUT /state/device/i2c:1:1:4 {"isOn":0}
0|REM        | [28/06/2024, 13:25:54] info: Setting device state {"type":"i2c","busId":1,"deviceId":1,"binding":"i2c:1:1:4","typeId":1,"id":1,"params":["4"]}
0|REM        | [28/06/2024, 13:25:55] debug: Persisting Configuration data... /home/brent/relayEquipmentManager/data/controllerConfig.json
0|REM        | [28/06/2024, 13:25:55] debug: 14 - Sequent 4rel4in v4 Executed read command 0x03 byte read:0x00
0|REM        | [28/06/2024, 13:25:55] debug: 14 - Sequent 4rel4in v4 Executed read command 0x00 byte read:0x01
0|REM        | [28/06/2024, 13:25:55] error: Error getting Sequent 4rel4in v4 digital input value for inDigital1.value
0|REM        | [28/06/2024, 13:25:55] error: Error getting Sequent 4rel4in v4 digital input value for inDigital2.value

[brentk7]

Does anybody have any pointers on what I can do to troubleshoot or help fix this issue?

[rstrouse]

I will try to get to it later this week. Unfortunately, I do not have one of these boards so I need to see if Sequent changed the registers for the inputs in their code.

[brentk7]

Much appreciated - please let me know if you need any info, logs or testing.

[rstrouse]

Update your relayEquipmentManager. I checked all the registers and the registers seem to match the 4rel4in from the Sequent codebase. It should be reading the correct i2c registers.

[brentk7]

I have just pulled the latest version from github and am still getting the same error

[rstrouse]

Have you installed the cli from sequent to see if it works?

[brentk7]

Yes - works fine from sequent cli and from sequent Node Red

[rstrouse]

I don't know why I was thinking that it was not able to retrieve the values from the device. As it turns out even your log shows a successful read of the register. However, the caught exception below reflects that it was not able to find the channel value for the input. I realized this last night and let it run all night pulling mock values.

Update your REM and let me know if it is doing its thing with the hardware.

[brentk7]

Thanks that has fixed it. Just a note that the reaction with this is very slow (I have to hold the button in for at least a second). I assume this is due to some polling delays by REM?