Sequent Smart Fan V6

[jgagnon5541]

I just received three modules from Sequent, the BAS, 8 relays board and the Smart Fan V6. Both BAS and 8 relay board work fine. The Smart Fan however does not work on V4 or <V4. All signs show that it should work. Displays CPU temp, show fan power output but the fan does not turn on. I did test the fan separately and it works fine. The Sequent documentation for the V6 is nonexistent on their website but I did notice this note under the description which I suspect is probably the problem "(Ver. 6.0 uses also GPIO 12)".
If it run the code from Sequent let say "fan 0 pwr 100" I get: "Failed to open gpio direction for writing!"

Any ideas where to go from here?

[rstrouse]

Hmmm. That device doesn’t use gpio triggers it uses I2c. Does it show the reported version?

[sberkovitz]

Just started playing with REM and I also have the v6 Board. In my case, it will also continually crash REM with the following error

0|REM      | /home/steven/git/relayEquipmentManager/boards/Constants.ts:238
0|REM      |                 if (typeof fn !== 'undefined' && typeof fn[to.toLowerCase()] === 'function') return fn[to.toLowerCase()](val);
0|REM      |                                                               ^
0|REM      | TypeError: Cannot read properties of undefined (reading 'toLowerCase')
0|REM      |     at Object.convertUnits (/home/steven/git/relayEquipmentManager/boards/Constants.ts:238:63)
0|REM      |     at SequentSmartFan.get fanCurve [as fanCurve] (/home/steven/git/relayEquipmentManager/i2c-bus/SequentSmartFan.ts:42:57)
0|REM      |     at SequentSmartFan.setOptions (/home/steven/git/relayEquipmentManager/i2c-bus/SequentSmartFan.ts:128:31)
0|REM      |     at I2cBus.setDevice (/home/steven/git/relayEquipmentManager/boards/Controller.ts:2529:61)
0|REM      |     at I2cController.setDevice (/home/steven/git/relayEquipmentManager/boards/Controller.ts:2137:26)
0|REM      |     at /home/steven/git/relayEquipmentManager/web/services/Config.ts:275:27

Sequents tool reports hardware version 4, even though the silkscreen says 7

steven@pi:~/git/SmartFan-rpi $ fan 0 board
Hardware version 4.0

[sberkovitz]

I have been working on getting the v6 working. I need to keep cleaning this up before I submit a PR back to the original repo, but in the meantime, you can pull from https://github.com/sberkovitz/relayEquipmentManager/tree/smartfan-v6.

The v6 unit is very different than the original with far less capabilities.

Note there is also an GPIO mapping change in here to accommodate the new Bookworm OS in pinouts/raspi.json; I am not yet sure how to properly generalize this so it remains compatibile with all units, ideally REM needs to transition to libgpiod as well

[rstrouse]

I took a look at the mapping for gpio and I think you may be mistaken as there is no GPIO539 on a Broadcom chipset. What you are lookin at is a conversion to a 4byte integer where the upper short is actually a mask. In the file you changed it simply has bit 2 set on the upper byte so GPIO539 is actually Broadcom 27. Perhaps the issue is that bookworm needs a 32bit value.

I will post up some changes for the above unit calculations. The error you are receiving is because the code is trying to normalize the temperature into a common unit and unfortunately it does not have the source units set in the configuration. I think that originally came from the board.

[sberkovitz]

I did some more work on this (https://github.com/sberkovitz/relayEquipmentManager/commit/36383279eabb9a36ccb64b270257573bb512d977) - it seems these values are different on the Pi 5, as well as different in Bookworm vs "Legacy OS" (as they seem to be calling it). I think you're right about it needing the full 32 bit value, but it also seems like newer devices will not be consistent. Ultimately this is why they want us to use libgpiod instead of the depricated approach the onoff module takes. In the meantime, I added a new board configuration instead of updating the existing one, should ensure it remains backwards compatible.

[rstrouse]

I pushed up some changes for the smartfan that fixes the missing units issue.

Ultimately this is why they want us to use libgpiod instead of the depricated approach the onoff module takes

I have found why your GPIO numbers seem so strange. The pi engineers are now identifying gpios by touple which includes the chip id (2) in the gpio. Honestly, this is the same approach as other boards such as the orange pi and probably what raspberry should have been doing all along. Perhaps there is a future for multiple gpio headers on the same board. For now the problem is that the pi 5 does not have the gpio chip embedded (chip id 0). It is external to the cpu on chip id (2).

Frankly, gpio has been a debate for a long time. If you rewind a few years ago these same folk yapping about libgpiod now were pushing the bcm libs and goofball wiring pi schemes mapping to the pin number. That route would have expired a long time ago. I am not quite sure where to go from here since there are no interrupts supported in the node modules.

[sberkovitz]

I have an update which provides support for the v6 board on both versions of raspi-os. It is relatively low risk (I think) and should not break anything existing. It's not necessarily the most elegant and there is room for code re-use between the new module and the previous, but it's working.

Do you want me to create a PR to submit this back?

[tagyoureit]

Thank you for this contribution.

[jgagnon5541]

I still have issue with the V6 fan. Step taken git pull npm i set my unknow I2C device to Sequent Smart Fan v6+ Once I set it to active save and restart the server I get this error: linux [20/06/2024, 08:18:50] info: Starting up SSDP server [20/06/2024, 08:18:50] info: Initializing GPIO Pins 1 [20/06/2024, 08:18:50] info: Configuring Pin https://github.com/rstrouse/relayEquipmentManager/issues/32 Gpio https://github.com/rstrouse/relayEquipmentManager/issues/12:low on Header 1 Edge: none. {"activeLow":false,"reconfigureDirection":false} [20/06/2024, 08:18:50] info: Server is now listening on 0.0.0.0:8080 Error: EINVAL: invalid argument, write at Object.writeSync (node:fs:888:3) at Object.writeFileSync (node:fs:2176:26) at exportGpio (/home/pi/relayEquipmentManager/node_modules/onoff/onoff.js:18:8) at new Gpio (/home/pi/relayEquipmentManager/node_modules/onoff/onoff.js:172:36) at GpioController.initPin (/home/pi/relayEquipmentManager/gpio/Gpio-Controller.ts:103:36) at GpioController.initPins (/home/pi/relayEquipmentManager/gpio/Gpio-Controller.ts:142:28) at GpioController.init (/home/pi/relayEquipmentManager/gpio/Gpio-Controller.ts:22:14) at /home/pi/relayEquipmentManager/app.ts:22:38 at processTicksAndRejections (node:internal/process/task_queues:96:5)

[sberkovitz]

Are you running Raspberry Pi Bookworm? If so, edit your controllerConfig.json and set controllerType "controllerType": "raspi-4b-bookworm"