-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to send IR code #37
Comments
Hi @grosch, On which distributions and release are you using ANAVI Infrared pHAT on your Raspberry Pi? On Debian based distributions, including the Raspberry Pi OS, you can retrieve it with the command There were some major changes in the way LIRC works with Raspbian Buster as explained in details here: I see in some of your configuration Best regards, |
@leon-anavi I'm honestly struggling with the docs because this stuff is all new to me, and so I don't know what's out of date and what's not, nor what most of these config items do, so I'm just blindly doing copy/paste of the configurations :(
I do see in my I forgot to include this config file: pi@piir:~ $ grep -v ^\# /etc/lirc/lirc_options.conf
[lircd]
nodaemon = False
driver = default
device = /dev/lirc0
output = /var/run/lirc/lircd
pidfile = /var/run/lirc/lircd.pid
plugindir = /usr/lib/arm-linux-gnueabihf/lirc/plugins
permission = 666
allow-simulate = No
repeat-max = 600
[lircmd]
uinput = False
nodaemon = False |
OK, I rebuilt from source as shown in your URL and I commented out the last two lines of
|
Hi @grosch,
Yes, because you are using Raspbian GNU/Linux 10 (buster). Have you applied Have you restarted the Raspberry Pi after changing Thanks, |
Hi @leon-anavi, Yes, I applied the patch and I've rebooted more then once since doing that. |
hm, could please share your whole current Thanks, Leon |
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
#dtoverlay=vc4-fkms-v3d
#dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17
dtoverlay=gpio-ir,gpio_pin=18
dtoverlay=gpio-ir-tx,gpio_pin=17 |
hm, everything looks good in Is I will try to reproduce the issue with a fresh Raspberry Pi OS on my side in the coming days. Thanks, Leon |
Yes sir:
|
Was this ever resolved? Facing the same issue with a recently purchases phat. |
Hi @indieisaconcept, Yes, this issue is outdated because there is a new LIRC version with recent Raspberry Pi OS release. In December the documentation was updated LIRC 0.10.1-6.3. With this LIRC version there is no need to apply any patches so the installation is now easier. However, the configuration process is still required. As noted in the user's manual in Which Raspberry Pi OS and LIRC version are you using? Have you managed to successfully scan a remote control? Best regards, |
Hi @leon-anavi, I am running Bullseye with kernel 5.15.8 and LIRC 0.10.1-6.3. I have been able to successfully scan multiple remotes and execute commands in response to received codes using irexec. Unfortunately transmitted does not appear to be working at all. Reviewing the logs for lircd.service I see Jan 30 22:43:29 indiepiir lircd-0.10.1[678]: Info: Using remote: ANI-PIP-41UHD.
Jan 30 22:43:29 indiepiir lircd-0.10.1[678]: Info: Using remote: SE-020401.
Jan 30 22:43:29 indiepiir lircd-0.10.1[678]: Info: Using remote: aktimate-mini.
Jan 30 22:43:29 indiepiir lircd-0.10.1[678]: Notice: lircd(default) ready, using /var/run/lirc/lircd
Jan 30 22:43:46 indiepiir lircd[678]: lircd-0.10.1[678]: Notice: accepted new client on /var/run/lirc/lircd
Jan 30 22:43:46 indiepiir lircd[678]: lircd-0.10.1[678]: Info: Cannot configure the rc device for /dev/lirc0
Jan 30 22:43:46 indiepiir lircd-0.10.1[678]: Notice: accepted new client on /var/run/lirc/lircd
Jan 30 22:43:46 indiepiir lircd-0.10.1[678]: Info: Cannot configure the rc device for /dev/lirc0
Jan 30 22:43:46 indiepiir lircd[678]: lircd-0.10.1[678]: Info: removed client
Jan 30 22:43:46 indiepiir lircd-0.10.1[678]: Info: removed client Thanks |
Hi @indieisaconcept, Thank you for sharing the logs. It looks like a software configuration issue, possibly due to not properly scanned code. Other people have experienced similar issue with bad What remote controls are you using? Can you have a look and check if the scanned values in Btw something that might be useful during scanning, LIRC documentation recommends if it fails to recognize the protocol of the remote control you should use the
Best regards, |
Back to the Original Poster (tm): the issue was never resolved, and I'm able to reproduce. The symptom: able to read a remote using irrecord, no problem. When I try to use irsend to transmit, the error is returned: "HARDWARE DOES NOT SUPPORT SENDING". The issue appears only on the raspberry-pi 3B with 32-bit OS... I have tried ubuntu jammy as well as raspbian bullseye with the same results. I have a working ubuntu jammy 64bit raspberry-pi 4B with the same setup and it works fine! We have the following log.
The config.txt has:
On boot we see the devices:
My OS and kernel version etc:
Is there anyone who can help me figure this out? I had hoped to repurpose my 4B for another project and instead use the old 3B to control the minisplit... thanks -bruce. |
@waltonbruce, what are the lirc versions on raspberry-pi 3B with 32-bit OS and on the ubuntu jammy 64bit raspberry-pi 4B? You can retrieve the LIRC version by running the following command in a terminal:
|
Hi Leon, I don't have access to the pi's currently, I will follow up when I get to the site to have them both plugged and online. They are both running ubuntu 22.04 and updated to current release distribution for each architechture. Unless I've done something horribly wrong each machine is running identical released code for lirc. https://launchpad.net/ubuntu/jammy/arm64/lirc/0.10.1-6.3ubuntu1 The reason for my posting was being mystified why 32 vs. 64 bit OS might behave differently with this gpio hardware. I'll get back to this thread in a few days. thanks -bruce. |
Hi Leon, Verified that both hosts are running same version of lircd.
Still looking for more clues as these are back online for awhile now. thx |
I'm trying to get started with the Anavi Infrared pHAT on my PI. I was able to learn the IR codes, but I can't send. When I try to send a code via
irsend SEND_ONCE HunterDouglasBlinds KEY_UP
it says:I have this in my config files:
The text was updated successfully, but these errors were encountered: