Controlling a DPG1C - crash when reaching limits, followed by a shift in displayed height

[Nepomucene]

Hi there,
I have managed to control a DPG1C. I can monitor and and send to sit and stand position.
The heights displayed are not consistent with the height displayed on the DGP1C's screen or the app. Until a crash occurs, the offset seems consistent.
The problem is when the desk reaches a limit, physical or soft (limit set in the DPG1C itself), the script crashes, and the heights have sometimes a new offset.

When crashing the output is:

Height: 1196mm Target: 1092mm Speed: 0mm/s
Traceback (most recent call last):
File "/home/pi/.local/bin/idasen-controller", line 10, in
sys.exit(init())
File "/home/pi/.local/lib/python3.7/site-packages/idasen_controller/main.py", line 393, in init
asyncio.run(main())
File "/usr/lib/python3.7/asyncio/runners.py", line 43, in run
return loop.run_until_complete(main)
File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
return future.result()
File "/home/pi/.local/lib/python3.7/site-packages/idasen_controller/main.py", line 387, in main
await stop(client)
File "/home/pi/.local/lib/python3.7/site-packages/idasen_controller/main.py", line 201, in stop
await client.write_gatt_char(UUID_COMMAND, COMMAND_STOP)
File "/home/pi/.local/lib/python3.7/site-packages/bleak/backends/bluezdbus/client.py", line 815, in write_gatt_char
assert_reply(reply)
File "/home/pi/.local/lib/python3.7/site-packages/bleak/backends/bluezdbus/utils.py", line 23, in assert_reply
raise BleakDBusError(reply.error_name, reply.body)
bleak.exc.BleakDBusError: [org.bluez.Error.NotPermitted] Write acquired

[rhyst]

Everyone seems to have a very different experience with their DGP1C 😆

I think the other thread on DPG1C issues proved that its very difficult for me to debug these issues without having a DPG1C.

If you're willing to debug it and edit the code yourself then I can offer help.

[Nepomucene]

The initial issues I had with it were actually not related to the controller, but to the host used (raspberry pi4) which was throwing bluetooth errors. Once I disabled sap, and found acceptable parameters for the config.yaml file (complex as numbers are changing), the monitoring and sending sit/stand/move to worked ok.

Sadly not sure I'll be able to get anywhere debugging (i'll still try).
Main questions are:

• Is the current height value read as is from the bluetooth data or calculated?
• Is the bluetooth data sending info when a limit (hard or soft) is reached?

[rhyst]

The height comes from subscribing to the characteristic. So the desk sends a value which is converted from some byte encoding to a number, and then its converted to millimetres. It's possible the DPG1C uses a different encoding but maybe I would expect the number coming out to be pretty random if that was the case.

As far as I know no information is sent about limits. On the Idasen desk if the desk just will not move beyond the hard limit of the desk's maximum and minimum heights but it does not cause the script to crash, though it will timeout because the target height is never reached. There are no soft limits for the Idasen so I don't know anything about that.

[Nepomucene]

Looking at the RawToMm formula made me realise that I misunderstood the concept of base height, and the error was due to reaching negative raw numbers => This is solved (classical keyboard chair interface error)

But guess what? After a full day of being able to send commands to the controller, I am now stuck in the read only state reported by others. Tried the following

• un-pairing/re-pairing
• rebooting raspi
• rebooting controller
• Forgetting desk bluetooth entry on my phone

Still Ok read, impossible to write (send commands)

[Nepomucene]

Re-connected the desk to the iphone app. Did a minor move from the iphone app. Killed the app, and sent a --sit
=> Worked!
Probably should merge this issue and number 32 as it looks like this is the same: Some kind of Wakeup issue

[rhyst]

Thanks for confirming! Closing in favour of #40

[voruti]

Thanks for confirming! Closing in favour of #40

Do you mean #32?

[rhyst]

I do 😆, thank you for correcting