September 20, 2020
Remove Work-In-Progress from documentation
Version 0.1.0a0.post1 was yanked for a clearer version number
September 15, 2020
The default LED symbols are now big non-ASCII signs:
🛑 : LED turned ON ⚪ : LED turned OFF
NOTE: the default symbols used by all GPIO channels can be modified with
LED symbols for each channel can be modified with
Channel names can now be displayed instead of channel numbers in the terminal:
🛑 [LED 1] 🛑 [LED 2] 🛑 [LED 3] ⬤ [lightsaber]
NOTE: these classes used to be in
Pin.channel_id: unique identifier
Pin.channel_name: displayed in the terminal along each LED symbol
Pin.channel_number: used to be called
Pin.channel_type: used to be called
gpio_functionand refers to the type of GPIO channel, e.g. 1 (GPIO.IN) or 0 (GPIO.OUT).
Pin.led_symbols: each pin (aka channel) is represented by LED symbols if it is an output channel
Manager.default_led_symbols: defines the default LED symbols used to represent each GPIO channel in the terminal
New functions in
setchannelnames(): sets channels names for multiple channels
setchannels(): sets the attributes (e.g.
led_symbols) for multiple channels
setdefaultsymbols(): changes the default LED symbols used by all output channels
setsymbols(): sets the LED symbols for multiple channels
wait(): waits for the threads to do their tasks and raises an exception if there was an error in a thread’s target function. Hence, the main program can catch these thread exceptions.
The keyboard listener thread in
SimulRPi.manageris now an instance of
KeyboardExceptionThread(a subclass of
pynput.keyboard.Listener). Thus, if there is an exception raised in
on_release(), it is now possible to catch it in the main program
If two channels use the same channel numbers, an exception is now raised.
accepts the new option
-awhich will make use of ASCII-based LED symbols in case that you are having problems displaying the default LED symbols which use special characters (based on the UTF-8 encoding). See Display problems.
all simulation-based examples involving “LEDs” and pressing keyboard keys worked on the RPi OS (Debian-based)
August 14, 2020
SimulRPi.GPIO, the package
pynputis not required anymore. If it is not found, all keyboard-related functionalities from the
SimulRPilibrary will be skipped. Thus, no keyboard keys will be detected if pressed or released when
pynputis not installed.
This was necessary because Travis was raising an exception when I was running a unit test: Xlib.error.DisplayNameError. It was due to
pynputnot working well in a headless setup. Thus,
pynputis now removed from requirements_travis.txt.
Eventually, I will mock
pynputwhen doing unit tests on parts of the library that make use of
Started writing unit tests
August 9, 2020
Tested code examples on different platforms and here are the results
On an RPi with
RPi.GPIO: all examples involving LEDs and pressing buttons worked
On a computer with
macOS: all examples involving “LEDs” and keyboard keys worked
RPi OS [Debian-based]: all examples involving “LEDs” only worked
NOTE: I was running the script
pynputdoesn’t detect any pressed keyboard key even though I set my environment variable
PYTHONPATHto etc/sudoers and ran the script with
sudo. To be further investigated.
[NOTE: tested the code examples with
[EDIT: use Initial release]