IR transmitter not working on Raspberry Pi - raspberry-pi

I am trying to turn on my TV using a Raspberry Pi.
I have followed the below instructions and added my remote config file, however, am having no luck! Any suggestions.
When running sudo /etc/init.d/lircd status, I get
lircd.service - Flexible IR remote input/output application support
Loaded: loaded (/lib/systemd/system/lircd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2018-11-11 13:27:07 UTC; 5min ago
Docs: man:lircd(8)
http://lirc.org/html/configure.html
Main PID: 334 (lircd)
CGroup: /system.slice/lircd.service
└─334 /usr/sbin/lircd --nodaemon
Nov 11 13:32:23 raspberrypi lircd[334]: lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:23 raspberrypi lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:42 raspberrypi lircd[334]: lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:42 raspberrypi lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:42 raspberrypi lircd[334]: lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:42 raspberrypi lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:54 raspberrypi lircd[334]: lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:54 raspberrypi lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:54 raspberrypi lircd[334]: lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:54 raspberrypi lircd-0.9.4c[334]: Info: removed client
Here are the steps I took to set it up.
# Add the following lines to /etc/modules file
lirc_dev
lirc_rpi gpio_in_pin=18 gpio_out_pin=17
# Add the following lines to /etc/lirc/hardware.conf file
LIRCD_ARGS="--uinput --listen"
LOAD_MODULES=true
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
# Update the following line in /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17
# Update the following lines in /etc/lirc/lirc_options.conf
driver = default
device = /dev/lirc0
$ sudo /etc/init.d/lircd stop
$ sudo /etc/init.d/lircd start
# Check status to make lirc is running
$ sudo /etc/init.d/lircd status
# Reboot before testing
$ reboot

Just run into the same problem. There are two main parts to it:
Part 1: new LIRC config
With the new version on lirc 0.9.0+, the configuration needed is much less:
The driver is already included in the kernel, no need to edit anything in modules
The new config syntax is much different, there's a shell script provided to change an old config to the new one. Run: sudo /usr/share/lirc/lirc-old2new.sh
To summarise, you only need to change the /etc/lirc/lirc_options.conf. In particular, you need to edit the lines to driver = default AND device = /dev/lirc0.
This should solve part 1.
Part 2: new IR drivers
As you can see in the /boot/overlays/README, the LIRC driver is being outdated. There are new ones provided for IR input and output. The driver for IR output is the new gpio-ir-tx. You need to use that instead of lirc-rpi in your /boot/config.txt.
In summary, change dtoverlay=lirc-rpi,gpio_out_pin=17,gpio_in_pin=13 to
dtoverlay=gpio-ir-tx,gpio_pin=17
NOTE the missing _out in the config. This driver only supports output, so no need for an input one. To handle inputs, use the gpio-ir one.

Related

How to start pyqt ui application using systemd

I have a pyqt5 UI application which I want to start using systemd service in raspberry pi. For this below is the service code:
[Unit]
Description=QT App
[Service]
User=pi
WorkingDirectory=/home/pi/Documents/qtproj
Environment=DISPLAY=:0
ExecStart=/bin/bash '/home/pi/Documents/qtproj/start_app.sh'
Restart=always
RestartSec=10s
[Install]
WantedBy=graphical.target
As per above code, I am starting start_app.sh script which loads few of the library and then finally start python3 pyqt5 application. When I am starting the above service, it stays in inactive status:
● myqt.service - QT App
Loaded: loaded (/etc/systemd/system/myqt.service; disabled; vendor preset: en
Active: inactive (dead)
Jul 13 09:47:57 pi systemd[1]: Started QT App.
Jul 13 09:47:57 pi sudo[7861]: pi : TTY=unknown ; PWD=/home/pi
Jul 13 09:47:57 pi sudo[7861]: pam_unix(sudo:session): session opened
Jul 13 09:47:58 pi bash[7860]: No protocol specified
Jul 13 09:47:58 pi bash[7860]: qt.qpa.screen: QXcbConnection: Could no
Jul 13 09:47:58 pi bash[7860]: Could not connect to any X display.
Jul 13 09:47:59 pi sudo[7861]: pam_unix(sudo:session): session closed
Jul 13 09:47:59 pi systemd[1]: myqt.service: Main process exited, code
Jul 13 09:47:59 pi systemd[1]: myqt.service: Failed with result 'exit-
Jul 13 09:48:05 pi systemd[1]: Stopped QT App
From the above status its clear that its not able to connect to display although I have give graphical.target. Can anyone please tell me how can I create a systemd service for pyqt5 application. Please help. Thanks
if it is a gui app (graphical USER interface), a logged in user is a requirement.
why not run it from a sytem wide .profile or similar for you system?
for bash that is /etc/profile.

Failed to load nf_conntrack

[root#name ~]# systemctl status firewalld -l
* firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
Nov 17 18:47:24 strike325 systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 17 18:47:25 strike325 systemd[1]: Started firewalld - dynamic firewall daemon.
Nov 17 18:47:25 strike325 firewalld[1176]: WARNING: ipset not usable, disabling ipset usage in firewall.
Nov 17 18:47:26 strike325 firewalld[1176]: ERROR: Failed to load nf_conntrack module: modprobe: ERROR: could not find module by name='nf_conntrack'
modprobe: ERROR: could not insert 'nf_conntrack': Function not implemented
modprobe: ERROR: Error running install command for nf_conntrack
modprobe: ERROR: could not insert 'nf_conntrack': Operation not permitted
Nov 17 18:47:26 strike325 firewalld[1176]: E
RROR: Raising SystemExit in run_server
Nov 17 19:47:16 strike325 systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 17 19:47:17 strike325 systemd[1]: Started firewalld - dynamic firewall daemon.
Nov 17 19:47:17 strike325 firewalld[2689]: WARNING: ipset not usable, disabling ipset usage in firewall.
Nov 17 19:47:18 strike325 firewalld[2689]: ERROR: Failed to load nf_conntrack module: modprobe: ERROR: could not find module by name='nf_conntrack'
modprobe: ERROR: could not insert 'nf_conntrack': Function not implemented
modprobe: ERROR: Error running install command for nf_conntrack
modprobe: ERROR: could not insert 'nf_conntrack': Operation not permitted
Nov 17 19:47:18 strike325 firewalld[2689]: ERROR: Raising SystemExit in run_server
I've recently purchased a VPS using Centos 7 (x64) and I'm having some trouble with my firewalld. I found the fix here but unfortunately it's no longer working for me. Any help would be appreciated as I haven't been able to find any permanent fixes.
Other fix attempts so far:
restart dbus
restart firewalld
Reverting and locking the version of firewalld (temporary fix)
I was going to post my fix in a while now (I'm supporting a number of servers, all affected with the same issue), but haven't had the time.
But your question made me motivated to finally write it down.
The solution from this post is:
create a script which generates modules.builtin file specific to your current kernel
create a SystemD unit which automatically recreates the same before FirewallD during startup (useful in case the kernel is upgraded).
In this way, you permanently solve the issue without hacking a bit of FirewallD code.
Workaround is to downgrade firewalld to 7.6:
wget http://vault.centos.org/7.6.1810/os/x86_64/Packages/firewalld-0.5.3-5.el7.noarch.rpm http://vault.centos.org/7.6.1810/os/x86_64/Packages/firewalld-filesystem-0.5.3-5.el7.noarch.rpm http://vault.centos.org/7.6.1810/os/x86_64/Packages/python-firewall-0.5.3-5.el7.noarch.rpm
yum downgrade firewalld-0.5.3-5.el7.noarch.rpm firewalld-filesystem-0.5.3-5.el7.noarch.rpm python-firewall-0.5.3-5.el7.noarch.rpm
and then lock firewalld from yum feature updates:
yum -y install yum-versionlock
yum versionlock firewalld firewalld-filesystem python-firewall
you can find more info in this thread.

PG::ConnectionBad Postgres Cluster down

Digitalocean disabled my droplet's internet access. After fixing the error (rollback to older backup) they restored the internet access. But afterwards I constantly get an error when deploying, I can't seem to get my Postgres database up and running.
I'm getting an error each time I try to deploy my application.
PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
So I used SSH to login to my server and check if my Postgres was actually running with:
pg_lsclusters
Results into:
Ver Cluster Port Status Owner Data directory Log file
9.5 main 5432 down postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log
Postgres server status
So my Postgres server seems to be down. I tried putting it 'up' again with:
pg_ctlcluster 9.5 main start After doing so I got the error: Insecure directory in $ENV{PATH} while running with -T switch at /usr/bin/pg_ctlcluster line 403.
And /usr/bin/pg_ctlcluster on line 403 says:
system 'systemctl', 'is-active', '-q', "postgresql\#$version-$cluster";
But I'm not to sure what the problem could be here and how I could fix this.
Update
I also tried updating the permissions on /bin to 755 as mentioned here. Sadly that did not fix my problem.
Update 2
I changed the /usr/bin to 755. Now when I try pg_ctlcluster 9.5 main start, I get this:
Job for postgresql#9.5-main.service failed because the control process exited with error code. See "systemctl status postgresql#9.5-main.service" and "journalctl -xe" for details.
And inside the systemctl status postgresql#9.5-main.service:
postgresql#9.5-main.service - PostgreSQL Cluster 9.5-main
Loaded: loaded (/lib/systemd/system/postgresql#.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2018-01-28 17:32:38 EST; 45s ago
Process: 22473 ExecStart=postgresql#%i --skip-systemctl-redirect %i start (code=exited, status=1/FAILURE)
Jan 28 17:32:08 *url* systemd[1]: Starting PostgreSQL Cluster 9.5-main...
Jan 28 17:32:38 *url* postgresql#9.5-main[22473]: The PostgreSQL server failed to start.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Control process exited, code=exited status=1
Jan 28 17:32:38 *url* systemd[1]: Failed to start PostgreSQL Cluster 9.5-main.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Unit entered failed state.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Failed with result 'exit-code'.
Thanks!
You better not mix systemctl and pg_ctlcluster. Let systemctl makes the calls to pg_ctlcluster with the right user and permissions. You should start your postgresql instance with
sudo systemctl start postgresql#9.5-main.service
Also, check the errors in the startup log. You can post them too, to help you figure out what's going on.
Your systemctl status also outputs that the service is disable, so, when the server reboots, you will have to start the service manually. To enable it run:
sudo systemctl enable postgresql#9.5-main.service
I hope it helps
It is mainly because /etc/hosts file is somehow changed.I have removed extra space inside /etc/hosts file.Use cat /etc/hosts
Add these lines into the file
127.0.0.1 localhost
127.0.1.1 your-host-name
::1 ip6-localhost ip6-loopback
And I have given permission 644 to /etc/hosts file.It is working for me even after the reboot of the system.

Raspbian / Debian Networkmanager not working as access point (mode = ap)

I'm trying to build an access point / hotspot with a Raspberry Pi, a wifi dongle and NetworkManager. I know that I can achieve this by just working with hostapd, dnsmasq and ifupdown - I even had it working with this. But I would like to use NetworkManager, as there is a nice Lib I can use to toggle the connections with Python. When reading about Network Manager it says that there are 3 kind of "modes" I can use. "Infrastructure", "ap" and "adhoc" - Infrastracture and "adhoc" are working, but not the ap one, which I need. This is what the Logs are giving me.
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: updating /etc/NetworkManager/system-connections/Hotspot_safe_save_075806
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: error: File did not exist or was not a regular file
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: updating /etc/NetworkManager/system-connections/Hotspot_safe_save_075806
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: error: File did not exist or was not a regular file
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: removed /etc/NetworkManager/system-connections/Hotspot.
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: updating /etc/NetworkManager/system-connections/Hotspot
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: error: invalid or missing connection property 'mode'
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: updating /etc/NetworkManager/system-connections/Hotspot
Jun 22 00:08:09 raspberrypi NetworkManager[2760]: keyfile: error: invalid or missing connection property 'mode'
What am I doing wrong? I Read that it could be that i need to recompile wpasupplicant - but with this i got some trouble. Any help appreciated.
Problem was that I was trying to do this with an Raspbian (Debian) Wheezy Image, which has an older NetworkManager. With the Jessie Image everything is working like a breeze now.
I could have compiled the newer NetworkManager by myself, but my skill level therefore is not that high ;)

Upgraded MongoDB and now shell dies with 'Illegal instruction'

I was running MongoDB v2.0.4.
I installed v2.2.2 and restarted.
The mongod process is running fine. Client applications are connecting and functioning fine.
But the mongo shell bombs out.
$: ~ mongo localhost/da
MongoDB shell version: 2.2.2
connecting to: localhost/da
Illegal instruction
$: ~
My "install" process was to download & unpack the .tgz and simlink all the binaries in bin to /usr/local/bin.
Here's what I see in the log on start.
Thu Jan 3 16:14:54 Mongo DB : starting : pid = 7225 port = 27017 dbpath = /var/lib/mongodb/ master = 0 slave = 0 32-bit
** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
** see http://blog.mongodb.org/post/137788967/32-bit-limitations for more
Thu Jan 3 16:14:54 db version v1.2.2, pdfile version 4.5
Thu Jan 3 16:14:54 git version: nogitversion
Thu Jan 3 16:14:54 sys info: Linux vernadsky 2.6.24-27-server #1 SMP Fri Mar 12 01:45:06 UTC 2010 i686 BOOST_LIB_VERSION=1_40
Thu Jan 3 16:14:54 waiting for connections on port 27017
This is running on a 32bit machine w/ 4GB memory and dual core PIII 1.4GHz processor.
Thinking this could be the 'floating point exception' mentioned on the MongoDB downloads page I tried the legacy-static build. The result is the same.
UPDATE
I think the limitations of running on an older 32 bit system make running v2.2.2 too unstable. The 2GB limit is easily exceeded (as evidenced by 'Got signal: 4' errors) when doing a repair operation or checking journal files on start up.
I've decided to revert to v1.2.2 using the Ubuntu package manager.
References:
https://jira.mongodb.org/browse/SERVER-5639
https://groups.google.com/d/topic/mongodb-user/gaAlONRvVSU/discussion
I had the same problem on Debian Squeeze 6.0.10 , an old 32-bit/i386 machine and with the 10gen distribution of the official mongodb instructions. On the instalation some problems with --configure of mongo-org-server and dependencies Trying to execute mongod "Illegal instruction" and
I had to purge the packages and install the 1.4.4 version through a simple apt-get install mongodb.