running rtl_433 container problem #239
Comments
|
i've already checked, using "lsmod", if there are some drivers in use and , as per advise from on github, used: |
|
First, if you're wondering at the comparative silence in response to your question, perhaps see this project is dormant. Second, once you read the above, I'd recommend joining the Discord channel. You'll find a link on the SensorsIot site (which is linked to in the above). You might find someone on the channel who knows about this stuff. You can also re-post your question as an issue on that repo if what I'm about to say doesn't help. Third, despite owning an SDR dongle for a couple of years, I'd never actually heard of rtl_433 until I read your issue. The only time I use my dongle is on an iMac with CubicSDR so I can "see" LoRa transmissions while I'm testing gizmos. I mention this so you can judge what I say next. Having dug around a bit, I now have some idea of what rtl_433 is meant to do and I'm thinking "cool, I might give that a whirl". But it'll probably be on the to-do list for a while. My "experience" is more in the IOTstack and Docker side of things, and it's that which has aroused my curiosity about this issue. I look at how rtl_433 is built for IOTstack and it occurs to me to ask you a couple of questions, including how long ago did you start to use rtl_433, did it ever actually work, how long has it been working, and do you have any theories on why it might have stopped? Sort of "please colour in the picture" kinds of questions. Why? Well, it looks to me like the gcgarner/IOTstack template for the rtl_433 container was set up a good two years ago. SensorsIot/IOTstack is using the same template. The template builds the service from scratch as a local container on top of debian:buster-slim. There is nothing wrong with this approach but there are some issues around building containers this way to make sure they are fit for purpose, so that's why I'd like to get a feeling for your timeframes. I just spun-up the container myself "as is" and noticed a whole bunch of grizzles as it went along: I doubt that Doxygen is an issue, SSL might not be, PkgConfig might be, while a missing SoapySDR could well be the cause of some conniptions. What might be going on is this chunk of the Dockerfile: See how it is installing dependencies (git, libtool, etc) then doing the clone from git and build steps. It's possible that just adding more dependencies will solve the problem. But don't rush to do anything yet. Keep reading. If that's the explanation, I can kind of understand how it happens. Two years is a long time. The rtl_433 repo moves on. The Debian base moves on. If nobody does any maintenance... The doubt you might sense in my words is because of: In short, my RPi4 can "see" my SDR dongle and the "as is" container itself seems reasonably happy: Yet you have this "claim" problem which I'm not seeing ... But, let's put a pin in that. As I said, two years is a long time and the world has moved on. After a fair amount of futzing around, I have come up with this replacement for rtl_433 in Some of that is from hertzg/rtl_433_docker, some of it is my own, based on experience. You'll need to do a bit of spade-work to try it out: then edit The two lines at the end that are commented-out are to do with "new menu" in SensorsIot/IOTstack but I will assume you will know whether you need that or not.
I also noticed the mention of "influxdb" in the Anyway, when I spin-up that revised service definition, I get: If you compare/contrast the two sets of logs outputs, they are pretty close. The same version and registration of "157 out of 186 device decoding protocols". The key differences:
The key similarity, of course, is: There were some swings and roundabouts getting to this point. I'm going to explain this so you don't fall into the same holes. I began with: but that pulled down an image built on top of Alpine Linux. Nothing wrong with that but it chucked up: I traced that to hertzg/rtl_433_docker Issues 3 which, strangely enough, is "closed" even though it still seems to be a current issue. I tried the recommended fix: but that was pretty ancient (January) and the "n" and "m" in "Registered n out of m device" was a bit lower. The logical conclusion is that whatever ails Alpine is taking a long time to fix. There can be good reasons to pin to old versions but I'd always try to find another way first. The list of tags at hertzg/rtl_433_docker implied Debian might work so I took myself to DockerHub, nosed around and selected: which seemed to work, so I took the pin off that to arrive at my final answer of: which also seemed to work. Along the way, I also set up a mosquitto subscriber: but it wasn't showing me anything. Influx was also remaining silent so I had no idea whether anything was actually working. I live in a small town in country NSW. Between the size of the town, my total ignorance of whether 433MHz is common in Australia (eg LoRa uses 915MHz as part of the ISM band), and the total silence from the monitoring tools, I wondered whether anything was happening… … but, then, I've also added: This is something you won't see in either the gcgarner or SensorsIot templates or, indeed, in the various examples. I just noticed these lines: I wondered what would happen if I mapped one of those. Opening a shell into the running container arrived at and restarted the container. The log changed to be: In short, there is an easy mechanism for "configuring" rtl_433, assuming that is something a sophisticated user of this container is likely to want to do. ANYWAY, it would be helpful if you could try this out and see if it solves your problem. Even if it doesn't we'll be slightly further forward because this service definition clearly "works", albeit with my dongle and RPi4. If you still get: then we will have narrowed it down to something peculiar about your system, and that will also get back to whether you are running gcgarner or SensorsIot, and when you installed it. Assuming you get the same "claim" message, I have a suspicion about the cause but I won't be able to confirm that until I get some more info from you. Hope this helps. |
|
Another thing I've just noticed in the influx database is: Those suffixes are from the container identifier, which gets regenerated each time a container is reconstructed from an image: Sort of faked me out for a while. I could see MQTT traffic but it wasn't showing up in the database. My guess is this is something that would be configurable. |
|
update on situation: my last try was to test different usb cables between rtl sharp dongle and my RB Pi4, last try was to connect RTL directly to Pi usb - it was barely possible as usb ports on Pi are very close to each other and as i'm using SSD drive as boot device and storage - my USB-SSD adapter plug is bit big. Finally i've managed to insert it and it is working now! At that time i was in hotel and in Node-Red debug node i found i can see many infos from TPS sensors of the cars parked around the hotel:D:D So i know that on Ford one tire was almost flat reporting 0.85 bar while everythig was ok on some Toyoda, Renault, another Fors and so on:) There was no weather stations around however but i'm sure i can pick my neighbours wheaterstations now:D |
|
@Paraphraser - thanks for your very complete response. I was having a problem getting the Mosquitto container to start correctly and you provided a breadcrumb with your comment:
... Thanks! |
|
Hi @cklann1 , Just like happened with my original response to this issue, what you've just written also makes me wonder whether you are using:
The reason why I'm wondering is because, with SensorsIot/IOTstack, there should never be any situation where Let me explain. If you are using SensorsIot then you should see the following: Everything in the I'll do a walk-through beginning with the default service definition: The only difference between that and what's in your The The relevant lines in that are: In words, "copy The In words, "compare the templates directory with the This check to replace missing files occurs every time the container starts. Here's a practical example: Mosquitto is running. Move to its persistent storage and see what's to be seen: Rename the configuration file so the Restart the container: See how Something has been added to the default since my Mosquitto was first spun up. I've never adopted that because my Put things back the way they were. You can see that, if A file differing from its template is left alone, as are any extra files that don't have a counterpart in the template directory. Two things should be evident:
My understanding is that There's more background on the theory of all this at Issue 331. I hope you see why you reporting needing to create
😎 |
|
Another question that comes up from time to time in the Mosquitto context is why the service definition has: In theory, that should be reducible to just: The reason is because the base image for mosquitto (the one that comes down from DockerHub and is the starting point for the iotstack-mosquitto image) defines: but leaves the other two undefined. To be compatible with that, we need to define the other two sub-directories explicitly. Given that Mosquitto pretty much won't work without a config and empty password file, their omission from the base image is curious. I keep hoping that, one day, I'll learn enough about Docker to be able to do a forehead-slap and say "Ah! Of course! That's why the base image for Eclipse-Mosquitto is built that way." |
Dear Fellows,
On my RB Pi4 i'm running IoTstack so docker with number of containers. One of the containers is rtl_433. When i enter the rtl_433 container via container manager (i'm using Portainer) and start its console and enter:
rlt_433
i'm getting:
usb_claim_interface error -6
I've read that it might be the problem that other piece of software accessed this usb prior rtl_433. But everything is inside container and i can not figure out how to obey this issue. I'm not Linux expert:(
I've connected to my headless Pi with Putty and tried to use "rtl_433" there but i got "-bash: rtl_433: command not found" which is not surprising for me as rtl is hidden inside container...
Please direct me toward good direction.
Thank you
The text was updated successfully, but these errors were encountered: