10/24/2021 at 15:02 •
One of the simpler items in creating is going to be a moving picture. This will just be a fancy frame around a small display I have, connected to a raspberry pi 3B. I will probably make my own video if I have time. I want it to look good with the screen in a portrait orientation, and I want it in black and white or sepia. I'll use vlc to play the video on a loop (using the loop between option to avoid black between loops).
For the sound part, lirc is set up to read a gpio IR receiver. The .conf file reads the nec protocol and the lircrc file calls irexec to play a sound when the button press is received. This is easy enough to set up.
Everything is mostly done here on the raspberry pi side. When I run it, I just need to start irexec as a daemon, then open the video in vlc, set the loop, mute it, and make it full screen.
Next steps are making a fancy frame for the screen.
10/21/2021 at 21:26 •
With the driver's set to nec, reading multiple devices with evdev is almost trivial. I modified the evdev example code for reading multiple devices with asyncio and I can see which device recurve input and what that event is. With just a slight modification to that, I can filter events so that I only see events with type == 4 and command = 1032. This is the signal I get from my Blaster. A basic if else statement allows me to trigger different actions based on which device reads the event. This is my end goal. The code is almost done. All I have to do is test it with a print() command, then I can add in my smart light controls and call functions to change the lights instead of printing the device. The hard part of this project is done finally.
There are a few caveats to this, which I might try to solve or I might just work around them. First, there's no guarantee currently that the same sensor will have the same device number on reboot. That's annoying since it means I would have to verify which sensor is which and potentially update the code before running it. I should be able to use udev rules to fix this.
The second annoying caveat is that the nec drivers get disabled on reboot. I tried using a cron talk to re-enable them on reboot but it isn't working currently. I may spend some time trying to fix this if I get time later. Alternatively I can put a few lines into the command prompt each time the pi restarts.
Next steps are to finalize the code, make and test the udev rules, and make extension cables for the sensors to check that they work with long cables and don't pick up each other's signals. I'll work on updating cron if I get the chance to, but getting everything else running is higher priority.
Update: The code is done and tested. There's not enough to say for a whole log. It works exactly as expected.
10/20/2021 at 20:28 •
I've been pursuing the python path for reading input events directly. Initially, this seemed like a dead end as cat wasn't giving any output for my ir devices. However, I found a suggestion to enable the nec driver on the devices. Mine only had lirc enabled, and I'm going to use the nec protocol for my Blaster. So I enabled nec on both my devices and suddenly the cat /dev/input/... worked for both devices! This bodes very well for pulling device input into python using evdev.
Next steps are reading inputs with evdev and making a script that can monitor multiple event devices simultaneously. Then I need to use that to trigger the light changes.
10/17/2021 at 14:42 •
Rather than using 4 sensors on one pi, I might be forced into using one sensor per board. This means I would need 4 more dev boards of some sort. What can I do to make this fancier and more elegant? Use ESP8266 boards and set up a MQTT server on my pi! Each ESP would publish messages to the server and the server could, presumably, run python scripts or somehow trigger inputs to a persistent python script when messages are received. It would also give me a fancy user interface. I've never used ESP boards before but they look amazing. It kind of makes me want to do the whole project as a single MQTT connected network so I could trigger everything from my phone as an alternative. I'll save that for future projects though. Part of my goal here was to use a many parts as possible that I already have. That means lots of arduino.
10/14/2021 at 05:24 •
Running multiple IR receivers on a single raspberry pi is not particularly difficult. Adding another dtoverlay to the config.txt works just fine and the lirc documentation explains how to add the second device. My issue is that I need the same command to map to a different keypress depending on which device picks it up. This is not an expected use of the software, so it isn't easy to do and it isn't documented.
As far as I can tell, lirc does not allow different mapping for each device. I think ir-keytable might, but it's lacking in documentation. I'm hoping that I can use ir-keytable to convert received signals to keypresses, then use lirc to turn those keypress into keyboard button presses. This will take some experimentation and might not even work.
10/14/2021 at 04:17 •
Not much to say here. It's exactly the same as the blacklight, just with a slightly different relay and different load. I'll be getting a 120V compatible relay with standard plugs that I can plug either a hair dryer or heat gun into.
10/13/2021 at 21:45 •
A mobile with themed paper cutouts will spin when triggered by IR. The motor will be a brushless motor, geared down and powered by a lipo. The brushless esc/bec will interface with and power an arduino. From a code perspective this is identical to the servo one.
Next steps are to build it.
10/13/2021 at 21:41 •
This creation will use a fake wall to create a room under my stairs. The door to this room will be hidden, and open/close by way of a motor when the IR signal is received.
This is still in the planning stages. An arduino will reciever the IR signal and trigger a brushless motor to drive using the servo library to control the esc. A four bar mechanism will drive the door back and forth through 90 degrees of rotation for each full rotation of the drive gear. The drive gear will be 3d printed with bumps on one side, offset 90 degrees from the connection point for the drive rod. When one of these bumps triggers a limit switch, the motor will be stopped and the door will be in the fully opened or fully closed state.
The motor will be geared down heavily since the motor I have are all designed for high speeds and low torque. Gearing will be accomplished with lego gears that I have hanging around already.
10/13/2021 at 21:32 •
This is my pet project within the larger project. The goal is to have the house crest of each HP house hanging on a wall. When one of them is blasted with IR, the smart lights on either side of the wall will change to the house colors of that house. I previously created a python script to change the smart lights when buttons were pushed. It will be fairly simple to modify that code for this purpose. The hard part will be getting separate inputs from 4 different IR receivers on one pi. I could use a separate pi or arduino for each receiver, but then I'd have to buy more components. It's also incredibly inelegant. It has to be 4 sensors on one pi.
Lirc should be able to read from 4 sensors individually. The challenge here will be getting the same signal to be interpreted differently based on which sensor it comes from. My current plan is to attempt to use lircrc files with irexec to interpret the reciever signals as keyboard button presses. These could be read by the python script to trigger lighting changes. However, I'm still working on this. It might not be possible. An alternative may be to read from the IR receivers directly in the python script. That will take more time and is only a backup plan at this point. I'm also looking into using ir-keytable if lirc isn't up to the task.
So far, I can translate an IR input to a remote keypress with the .lirc.conf file, then convert that to a keyboard keypress by using the lircrc file to call xdotool by way of irexec.
I'm still heavily in the learning and tinkering phase on this one. It's my main focus currently.
10/13/2021 at 21:16 •
Playing sound effects on an arduino is a huge pain. Playing sound from a raspberry pi is much easier. Receiving IR commands on a Pi takes a bit of work though.
For this part, I'm using lirc. I started with a clean install of the latest pi OS. I installed lirc, configured it for the default driver, and set the config.txt to read from the proper gpio pin. Then I tried to run irrecord. It failed. Over and over. So I found a config file for a similar remote and it worked just fine. I made a lircrc file with just one entry that will use irexec launch omxplayer when it gets the signal. That's it. When I push the remote button, the sound plays.
Next steps for this will involve not much really. Packaging I guess.