Accessing USB input in container in python

I have created a python script and it is in a container that is running on my Raspberry Pi Zero. I have also created an dockerfile to go with the container as well. When the script runs on the Rpi it is running how it should (I can see from the logs in balenaCloud).
The issue I am having is that the USB Input device (a barcode scanner) is not being inputted into the script that is running.
I assume this is because I need a link between the host and the container but I cannot seem to find anything for python.

FROM balenalib/rpi-debian-python:latest

RUN apt-get update
RUN apt-get install python3-pymongo

# Copy my application files
RUN mkdir -p apps
COPY ./apps/ ./apps/

# runs a sample app on container start
CMD ["python3", "apps/main.py"]

I have also tried with a USB keyboard and it still does not recognize any input.

Any guidance is appreciated

Maybe following github repository might guide you:

I have used it to get input from a USB keypad.

have a nice day.
Jan.

Hi Jan,

I did try that repo earlier but was getting an error. I think related to my incorrect choice of USB device in the variables. This was what was happening in the logs:

02.10.19 09:37:07 (+0100) Starting service ‘mqtt sha256:72382a50a4e55bda2680a947d8915ec5450477a42b5be6c3d5866c9d8787c798’
02.10.19 09:37:14 (+0100) Started service ‘mqtt sha256:72382a50a4e55bda2680a947d8915ec5450477a42b5be6c3d5866c9d8787c798’
02.10.19 09:37:13 (+0100) mqtt 1570005433: mosquitto version 1.6.7 starting
02.10.19 09:37:13 (+0100) mqtt 1570005433: Config loaded from /mosquitto/config/mosquitto.conf.
02.10.19 09:37:13 (+0100) mqtt 1570005433: Opening ipv4 listen socket on port 1883.
02.10.19 09:37:13 (+0100) mqtt 1570005433: Opening ipv6 listen socket on port 1883.
02.10.19 09:37:17 (+0100) Killing service ‘mqtt sha256:72382a50a4e55bda2680a947d8915ec5450477a42b5be6c3d5866c9d8787c798’
02.10.19 09:37:18 (+0100) mqtt 1570005438: mosquitto version 1.6.7 terminating
02.10.19 09:37:24 (+0100) Service exited ‘mqtt sha256:72382a50a4e55bda2680a947d8915ec5450477a42b5be6c3d5866c9d8787c798’
02.10.19 09:37:24 (+0100) Killed service ‘mqtt sha256:72382a50a4e55bda2680a947d8915ec5450477a42b5be6c3d5866c9d8787c798’

I was going into /dev to get a list of devices. But even when I connected/disconnected the device all the same would be displayed. Are they displayed somewhere else on the console?

The errors you are getting are related to the mqtt service (= mqtt broker)
So you are having a problem with the following lines in the docker compose file:

  mqtt:
    image: arm32v6/eclipse-mosquitto #https://hub.docker.com/_/eclipse-mosquitto   
    #image: panuwitp/mosquitto-arm
    ports:
      - "1883:1883"

Regarding your other question:

Are they displayed somewhere else on the console?

Normally the python-evdev2mqtt service is at startup logging all connected USB devices. Don’t you see anything in your balenaCloud dahsboard log window for this service ?

The only thing I am getting in my dashboard is the log I posted previously. That log repeats constantly.

In relation to those lines in the docker-compose file. Should they be modified in anyway?

Hi @junett ,

Just to understand, you’re not using a docker-compose for your original service, correct (the original post just lists the Dockerfile). When you push a Dockerfile to balena instead of a docker-compose, that service is privileged. As such, you should have full access to the /dev nodes on the host OS. This seems to suggest that the device isn’t showing up in the OS.

As a quick test, you should be able to SSH into the HostOS of the Pi Zero and look at the device nodes in /dev to see if the device you’re expecting to see is showing up. If it doesn’t, this would suggest that the input device is not being recognised if it doesn’t follow the standard USB HID. You might, in this case, be able to build an appropriate OOT kernel module for it which could be installed in the service container to access it (there’s an example of that here ).

Many thanks to @janvda for pointing at his repo as an example!

Best regards,

Heds

Hi @hedss ,

I’ve just checked and my device is showing up as hidraw0. (When I remove the device hidraw0 is no longer shown in /dev in the HostOS console.

Yes, you are correct. I am only using a Dockerfile. Do I need to put anything in the Dockerfile to be able to access the USB device?

Thanks

Hi @junett ,

If you’re just using a Dockerfile (and therefore a single service), there isn’t anything else you should have to do as that service should be privileged and showing up all the device nodes available on the host. You should also be able to SSH into your service container and look to see that /dev/hidraw0 is present. If it isn’t, but is in the host, let us know and if you can then give us the UUID of your device and grant access support, we’ll take a look for you!

Best regards,

Heds

Like @hedss also mentioned: just using dockerfile should work as by default is running in privileged mode.

So normally the following 3 files configuring the service python-evdev2mqtt in (see https://github.com/janvda/balena-python-evdev2mqtt/tree/master/python-evdev2mqtt) should be sufficient:

Maybe you can share your dockerfile
kr
jan

@hedss,
Just had a look and hidraw0 is present in the service container and present in the Host OS.
Would you still like me to grant access support?

Hi @junett,

If the device node is present in both OS in container, you should be able to use it from your application. Is there any way you can easily debug what your application is doing to see why it might not be picking up the scanner? Does it come with a reference piece of code to test it (some devices sometimes do)?

Best regards,

Heds

Hi @hedss,

There was no reference piece of code to test it. I have had it working with this Raspberry Pi as originally the pi booted to a desktop and I tested my script using that before attempting to move it all to Balena.

I wrote the script I am running myself so I know that it is waiting for an input but it is not receiving an input into the script as the logs show this is not happening.

I have already tried a different USB device and a keyboard and I get the same thing where the input is not received into the container.

Thanks,

Hi @junett ,

That’s very curious then. If you wouldn’t mind providing the UUID of the device and providing support access, I can have a look and see if I can see anything obvious?

Best regards,

Heds

@hedss,

I have allowed access for 3 hours. The UUID is: 38fb37140ea1bddd54adf20e0d739d2b

Thanks.

Thank you, I’ll take a look now.

1 Like

Hi,

This device appears to be offline again, did it get restarted/powered off?

Best regards,

Heds

@hedss

I saw that it went offline from BalenaCloud as well (I assumed it was something you were doing). I have not touched anything with the device and it is still powered up

Hi again @junett ,

I’ve had a look but it appears that everything should be working correctly. A USB keyboard should definitely work. As an experiment, if you use a development image and plug a keyboard in to the Pi, are you able to login using it? The only thing I can currently think of is if the ports aren’t working correctly.

Best regards,

Heds

Hi @hedss,

If I use another SD card with a different image (desktop) then the USB input works as it should. I have tried a keyboard and the barcode scanner.

I have also tried adding a new device on balenaCloud and flashing a new image onto a new SD card and using a new raspberry pi and I still get the same thing.

Further to this, I put a devlopment image on the rasberry pi, it asks me to log in, the keyboard input works and the barcode scanner also works. I can’t actually log in as it keeps telling me the log in is not valid but I can see the input being displayed.

Is there any way to check the ports through balenaCloud?

Thanks

Hi @janvda,

Here is my dockerfile:

FROM balenalib/rpi-debian-python:latest

RUN apt-get update
RUN apt-get install python3-pymongo

# Copy my application files
RUN mkdir -p apps
COPY . .

# runs a sample app on container start
CMD ["python3", "main.py"] 

main.py is in the same directory level as Dockerfile.

Thanks,