DeskPi Lite extra features

[crusader27529]

I bough my DeskPi almost two years ago, and I never was able to get the power button to safely shut down the RPI, but I did have the extra 2 front USB ports working.

Recently, I started to use the unit again, and installed a different RPI4 (2GB) and installed the current RPIOS. I've gone through the DeskPi install multiple times with no change. I'd really like to purchase the SATA M.2 add-on, but hesitate because of the current issues I have.

I found some closed issues that were related, but the 'new' install.sh didn't fix the issue. How can I see what's happening when the RPI starts and goes through the DeskPi part of the setup?

[magorium]

DISCLAIMER: I am not in any way affiliated with deskpi or their products nor their software. I am but another user with some programming background. Use any advise at your own risk.

I bough my DeskPi almost two years ago, and I never was able to get the power button to safely shut down the RPI, but I did have the extra 2 front USB ports working.

I am assuming you are talking about the product listed on this webpage

If so then AFAIK the repository you should be looking for is here

Recently, I started to use the unit again, and installed a different RPI4 (2GB) and installed the current RPIOS. I've gone through the DeskPi install multiple times with no change. I'd really like to purchase the SATA M.2 add-on, but hesitate because of the current issues I have.

In principle the adapter board (listed here ) is connected through one of the standard USB ports of your PI. As such the adapter board works exactly the same as any other 3th party external USB drive. You should not be having any difficulty attaching the adapter board and make it work (it should work automatically out of the box).

I found some closed issues that were related, but the 'new' install.sh didn't fix the issue. How can I see what's happening when the RPI starts and goes through the DeskPi part of the setup?

That is a bit difficult to answer because things are setup in such a way that they are installed as a service on your OS. There is no predefined order of 'happening'. The service runs in the background and acts when you either talk to the hardware or the hardware talks to the service (actually it is polling).

For more details about the inner workings a developer should be able to answer though the process is described at several places (in order for people to understand how the python scripts work).

Having said all that, you also indicated that you installed the latest raspi OS and quite frankly I do not know if the old python scripts still work for the new OS (which is now based on debian bookworm instead of the old debian bullseye)

[crusader27529]

I can assume that the script does work with the laterst RPI OS, as both the

dtoverlay=dwc2,dr_mode=host

and

dtoverlay=gpio-fan,gpiopin=14,temp=60000

are in the config.txt file.

I'm not sure that the serial stuff is installed, but I set the fan to run at 100%, and it doesn't run. At boot (I have the HW outside of the box so I can see what's happening) the fan appears to run at what I think is 100% for about 5-6 seconds and then stops, so the fan is functional and something can control it.

I'll try the python script in the reference......

[crusader27529]

Well, there is no /dev/ttyUSB0, so that's the probable issue with the power switch. I tried the pip3 install pyserial 'command', but the OS won't let it run, ever if I'm the root user.

Any idea how to get the ttyUSB0 device added?

I'll do some research, but DeskPi needs to come up with a solution that works with the current OS version from Raspberry Pi.

[crusader27529]

AFAICT, ttyUSB0 should 'connect' when a serial device is connected, so it implies that the DeskPi doesn't seem to 'connect' the way it needs to do........I wonder if the DeskPi HW is defective?

[magorium]

I'm not sure that the serial stuff is installed, but I set the fan to run at 100%, and it doesn't run.

You can check that by opening a terminal and enter

$ ls /dev/ttyUSB0

If the serial device exists it should return /dev/ttyUSB0 otherwise it returns an error (no such device)

or you can list all devices with

$ ls /dev

And try locate the ttyUSB device in the listed results (there should be one and only one).

If the overlay is placed correctly in the file /boot/firmware/config.txt (in case wondering, that is not a typo, for raspi OS based on Debian bookworm the config.txt file is actually located there) then this USB serial device should automatically be created and present itself to the OS.

If you used/installed the python scripts then you probably also need to install the pyserial python library (as stated in the readme ).

I am not sure if that is what you are currently dealing with but it can't hurt to verify either (I hope) :grin:

[crusader27529]

If I try this:

sudo pip3 install pyserial

or

sudo pip install pyserial error: externally-managed-environment

This environment is externally managed

To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install.

If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed.

For more information visit http://rptl.io/venv

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification.

I'm at a complete loss on how to proceed.

[crusader27529]

DeskPi SUPPORT.....

I found this: The MCU just accept serial port signal, once you connect raspberry pi to daughterboard via USB-C, and enable the device tree overlay: dtoverlay=dwc2,dr_mode=host and reboot the pi, it will generate a device /dev/ttyUSB0 and this device is the bridge from pi to MCU, and the MCU firmware has been already written to accept serial signals such as "pwm_xxx" xxx is from 0 to 100, and then MCU will contrl the fan speed via PWM signal, and once raspberry pi sending power_off to /dev/ttyUSB0 the MCU will start counting down, about 5-8 seconds, it will cut off the power from raspberry pi and turn on red led on push button of deskpi. so at this moment, it can not execute reboot or shutdown by just clicking the push button in front of the panel.

Obviously this does NOT work with the current RPI OS (Bookworm), and a resolution is needed.

No /dev/ttyUSB0 is created, so nothing related to the Safe Power Down will work. The front 2 USB posts also don't work, and I can only assume that it's related to the same issue......

[magorium]

@crusader27529 Please open a terminal and issue the following command

cat /boot/firmware/config.txt 

and then copy-paste the output from that command to a message so that we can have a look at it. Make sure to copy-paste every line as the correct order of some of the lines is of importance.

[crusader27529]

crusader2752939@rpi4-2:/boot/firmware $ cat config.txt

For more options and information see

http://rptl.io/configtxt

Some settings may impact device functionality. See link above for details

Uncomment some or all of these to enable the optional hardware interfaces

dtparam=i2c_arm=on

dtparam=i2s=on

dtparam=spi=on

Enable audio (loads snd_bcm2835)

dtparam=audio=on

Additional overlays and parameters are documented

/boot/firmware/overlays/README

Automatically load overlays for detected cameras

camera_auto_detect=1

Automatically load overlays for detected DSI displays

display_auto_detect=1

Automatically load initramfs files, if found

auto_initramfs=1

Enable DRM VC4 V3D driver

dtoverlay=vc4-kms-v3d max_framebuffers=2

Don't have the firmware create an initial video= setting in cmdline.txt.

Use the kernel's default instead.

disable_fw_kms_setup=1

Run in 64-bit mode

arm_64bit=1

Disable compensation for displays with overscan

disable_overscan=1

Run as fast as firmware / board allows

arm_boost=1

[cm4]

Enable host mode on the 2711 built-in XHCI USB controller.

This line should be removed if the legacy DWC2 controller is required

(e.g. for USB device mode) or if USB support is not required.

otg_mode=1

[cm5] dtoverlay=dwc2,dr_mode=host

[all] enable_uart=1

[all] dtoverlay=gpio-fan,gpiopin=14,temp=60000

[magorium]

Let me try and clean that up first

crusader2752939@rpi4-2:/boot/firmware $ cat config.txt
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details
# Uncomment some or all of these to enable the optional hardware interfaces

dtparam=i2c_arm=on #dtparam=i2s=on dtparam=spi=on
# Enable audio (loads snd_bcm2835)

dtparam=audio=on
# Additional overlays and parameters are documented
# /boot/firmware/overlays/README
# Automatically load overlays for detected cameras

camera_auto_detect=1
# Automatically load overlays for detected DSI displays

display_auto_detect=1
# Automatically load initramfs files, if found

auto_initramfs=1
# Enable DRM VC4 V3D driver

dtoverlay=vc4-kms-v3d max_framebuffers=2
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.

disable_fw_kms_setup=1
# Run in 64-bit mode

arm_64bit=1
# Disable compensation for displays with overscan

disable_overscan=1
# Run as fast as firmware / board allows

arm_boost=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.

otg_mode=1

[cm5] dtoverlay=dwc2,dr_mode=host

[all] enable_uart=1

[all] dtoverlay=gpio-fan,gpiopin=14,temp=60000

can you verify/confirm that indeed the sections named all do not have a enter before listing their entries ? If I quote your reply they did not contain an enter.

It should look like:

[cm5]
dtoverlay=dwc2,dr_mode=host

[all]
enable_uart=1

[all]
dtoverlay=gpio-fan,gpiopin=14,temp=60000

But never mind that detail, you are missing the overlay for your pi4.

Please edit your /boot/firmware/config.txt file and locate the [cm4] section. RIght above the [cm4] section and after the line which reads "arm_boost=1" add a new section named [pi4] and add the overlay line, e.g.

...
arm_boost=1

[pi4]
dtoverlay=dwc2,dr_mode=host

[cm4]
...

and reboot your pi. Then check if you now have the ttyUSB0 device present using the ls command and please report back if it did or not.

[crusader27529]

All the lines did indeed have an enter, meaning the commands started at the beginning of the line.

I added the

[pi4] dtoverlay=dwc2,dr_mode=host

and the front USB ports now work, and I think that the fan also now works.

BUT, although /dev/ttyUSB0 now exists, the power button still doesn't perform a safe shutdown. FYI, the switch for the power is set for the power NOT being on continuously, if that makes a difference.

So, we're making progress, and the install script didn't add/have the Ipi4] lines.

[magorium]

Thank for reporting back @crusader27529 crusader

All the lines did indeed have an enter, meaning the commands started at the beginning of the line.

OK, so that was related to an error between the copy and paste or the message software that ate them enters. That is good to know.

and the front USB ports now work, and I think that the fan also now works.

Great, as that is the most important step.

Now you know the hardware is working as intended and can be accessed.

So, we're making progress, and the install script didn't add/have the Ipi4] lines.

There is an error in the original installation script that incorrectly checks for the presence of an overlay entry in the configuration file but ignores the different sections (they are actually named filtering rules). Those sections were not a problem for the Raspi OS version based on Bullseye but it is for Bookworm. Unfortunately the installation script never considered that.

In theory using the [pi4] section isn't even necessary but the [all] section has an official explanation that is imho ambiguous in that it states to perform a "reset" of all previous sections in the config.txt.

Using the pi4 section makes sure the overlay is loaded as intended.

BUT, although /dev/ttyUSB0 now exists, the power button still doesn't perform a safe shutdown. FYI, the switch for the power is set for the power NOT being on continuously, if that makes a difference.

Ok, the last hurdle.

The issue (as you probably figured out yourself) is that the service that checks for the communication of the serial USB device is either not running or is not running as expected.

Assuming the install script itself did it's job correctly and installed the services and the python scripts and AFAIK there are two situation possible that is able to make it fail. 1) the python scripts do not work at all with Bookworm (I have no idea if this is the case) 2) the python serial library is not installed

You already stated that you have difficulty with installing the python serial library and I have to be very cautious there because my knowledge wrt python is about next to nothing.

The error message that you posted earlier did result in some hits during searches but I do not fully understand the implications.

So i am very sorry to say/ask that perhaps someone more knowledgeable on the subject is able to provide us with some helpful/useful feedback.

[magorium]

.... and 2 seconds after I posted I found this question and answer.

Could you try that advise (for python 3, I assume) @crusader27529 ?

[crusader27529]

I did this:

sudo apt install python3-serial # Python 3

and there was no change.....the power button still doesn't do a safe shutdown.

One of my original comments was related to adding the NVME adapter to the DeskPi, but it was not related to whether or not it would work, but related to official DeskPi support in general.

I appreciate you help more than you know, but I still haven't seen any obvious response to an real problem from DeskPi support directly, and that's very troubling.

I have another minor question....on the Lite PCB there's a small connector between the power button and then front USB ports, and I've no idea what it's used for....any ideas?

[magorium]

I am really struggling with the python stuff simply because I am not familiar with its setup (so basically doing blind searches).

One of my original comments was related to adding the NVME adapter to the DeskPi, but it was not related to whether or not it would work, but related to official DeskPi support in general.

Ah ok, in that case I indeed interpreted your question wrong. Apologies for that. Ofc in that case someone from the DeskPi Team should answer that.

One small remark/warning though. It is not an NVME adapter rather a M.2 adapter board. It does not support NVME SSD drives, only SATA SSD ones (the documentation on the product page of the adapter board explicitly mentions that).

I appreciate you help more than you know, but I still haven't seen any obvious response to an real problem from DeskPi support directly, and that's very troubling.

In my personal experience with these kind of products it is mostly about errors in communication and not so about the incentive.

I have another minor question....on the Lite PCB there's a small connector between the power button and then front USB ports, and I've no idea what it's used for....any ideas?

EDIT: If you are referring to the white looking connector then this is an alternative 5volt power.

Also figured out something else related to that board.

There is a switch next to the power button that can be set in two modes, D and E. D stands for fan always on and E let's the fan be software controlled.

The latter can be done twofold, either by using raspi-config and configuring fan control or by using the python script. The former allows to configure a certain temperature for the fan to kick in and the latter allows you to configure different treshold temperatures and corresponding fan-speeds (which allows for a more fine grained control).

[crusader27529]

I often use NVMI instead of using the generic term of M.2. I have a SATA M.2 to use with the M.2 add-on module, which I've just ordered.

I know about the switch, and tried both positions trying to get the power button to do a safe shutdown, with no positive result. I normally leave it in the E position.

I'm not sure that you're correct about that switch, since it obviously determines how the power switch works, determining if the RPI starts immediately when power is supplied or the power burron needs to be pressed to apply power to the RPI.

[magorium]

I know about the switch, and tried both positions trying to get the power button to do a safe shutdown, with no positive result. I normally leave it in the E position.

To my knowledge that switch has no impact on or relation with the power button. The switch is only there to determine how the fan can be controlled.

I'm not sure that you're correct about that switch, since it obviously determines how the power switch works, determining if the RPI starts immediately when power is supplied or the power burron needs to be pressed to apply power to the RPI.

No. afaik, the switch determines how the fan is suppose to be addressed. One position is to have the fan always turned on and the other to have the fan software controlled.

The power is controlled by the daughter-board itself. Whenever you shortly press the power button twice the board will send a signal to the serial port. One of the Python scripts is installed as a service and constantly polls the serial port to see if a message from the daughter-board arrives. Eventually a second script will check If a correct shutdown message was received by the daughter-board and will write back to the serial port to instruct the daughter-board to cut off the power and as a result your pi will/should turn off.

The reason this construction exists is to make it possible to do a safe shutdown of the operating system (and not just cut off the power).

But, I am not telling something new there. After all that process is written down in the readme of the deskpi_v1 repository and on the DeskPi website for the Deskpi Lite wiki.

Also there it is stated how one can install the required pyserial library (as in the python scripts itself) but I can imagine these instructions did not withstood time (and I do not know how to solve the installation issue you ran into)

[crusader27529]

After 3 weeks, DeskPi Support (are there people assigned to fix things?) has never responded. That shows their support is a joke..............

[magorium]

@crusader27529 It is a bit of a mixed situation. If you require after sales support then doing that here is not the correct location.

The repository here where you filed you complaints is there to address software related issues.

Developers tend to have a complete different agenda than after sales. So, your mileage may vary.

In the mean time I have figured why the python scripts do not work. With the newer releases of python, it is configured in such a way that it is run into a separated (for example sake let's say) virtual environment. That is not going to work during boot, but is required for the scripts in order to work as intended).

That is probably the reason that the developer switched to re-writing the scripts to c-code as that the compiled executables are able to run at boot-time.

Since the overlay is working for you I suspect that you might also be able to use the same solution. Mind you, suspect. You would have to verify with one of the Deskpi developers or in case you do not get a response contact after sales.

I could instruct how to verify this but I am not a Deskpi developer and/or employee and do not get payed anything for my time. If they want my help they can send me the hardware in order for me to test/verify my suspicions and try resolve the situation.

regards,