Greg Erskine wrote:
> Is it a one wire device?
>
> Have you loaded the appropriate w1-.tcz extension?
The DHT11/DHT22 family are not one-wire devices. They can be
bit-banged, from either the kernel (if you have the drivers) or from
userspace.
Turns out doing it from userspace works just
Thanks -- yes, I already have config.txt configured correctly, with:
"dtoverlay=dht11,gpiopin=24". There are no mentions of the overlay (or
the string "dht" in the kernel log.
But you did send me off to do more searching.
I've been assuming that I want to use the kernel driver for the DHT
I'm having a surprising amount of trouble finding the (presumably!)
pre-built dht11 and industrialio kernel modules, which are needed for a
DHT22 temperature sensor I'd like to add to one of my pCP boards.
The DHT11 is supported by a dtoverlay, so I'd be surprised if the
driver's dependencies
mr-b wrote:
>
> Is there any way to have a notification of pCP updates ( or other
> component updates) e.g. like LMS?
>
If you have a way of monitoring a website for changes (there are free
services for this, and android apps, and fairly simple shell scripts),
then you could set up to be
Okay. Non-published repo? Really? That definitely make pCP an
outlier! :-) Good to know, though -- I'll stop looking. ;-)
My local mods aren't all that big. Mostly a few long-running scripts
that I start from "User command #1", which lives in /home/tce. I think
I also needed to have
Got it. I'm on my own. ;-)
Thanks!
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=114828
I've looked for .filetool.lst in git, but it's not jumping out at me,
and the fact that it and .xfiletool.lst are both dot-files makes me
think they must be created from some other list or tool.
In order to get few more things backed up (since they contain local
mods), I've added several lines
A couple of questions, before I do my first in situ upgrade.
I assume that anything backed up (i.e., listed in /opt/.filetool.lst)
will survive the insitu upgrade, correct? Likewise, the modules
installed via onboot.lst?
I'm running 7.0.1. Is it okay to upgrade straight to 8.1, or do I need
FYI, Ralph just helped me learn (while diagnosing the SIGTERM thing)
that the shutdown bug doesn't happen if -C is used. I get the
impression (and I'm going to confirm with him) that -C should always be
used with USB devices that might be unplugged or turned off. (Clearly
it should shut down
coyrls wrote:
> Submit an Issue at https://github.com/ralph-irving/squeezelite ?
Perfect. Thank you.
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread:
Sure, maybe separating out the stop/start, and adding in the pkill,
would be better. In my testing I never saw an issue with the restart,
but it could be safer. Since the restart is happening when the device
is present, the squeezelite shutdown bug may not be triggered.
What should really
In any case, I won't be adding that to my script, because none of those
commands will work on my system. (I connect to the LMS server via an
ssh tunnel, so my LMS server address is actually localhost. I use a
custom -s option on the squeezelite config page to do this.)
So here's my current
Any reason you can't just use the "pcp" command (which I just stumbled
across). Seems safer than loading their internal files.
Code:
==kitchen(tc)>> pcp help
=
Basic
No -- SIGTERM is the default, for all versions of kill/pkill/killall.
For some reason, if the audio device has gone away (probably not a
well-tested scenario), one of squeezelite's threads doesn't die from the
first kill -TERM, but does die from the second.
I've put a similar workaround in my
Have you tried using SIGTERM again, rather than SIGKILL?
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
You'll be happy to know I'm seeing an incomplete kill of squeezelite on
my system as well. I'll look into it.
Note that squeezelite, while not killed completely, has been crippled:
2 of its 4 threads do die.
paul
> The cardname is then part of the $OUTPUT variable, e.g.
> "hw:CARD=DragonFly,DEV=0", from which 'DragonFly' would need to be
> extracted.
>
I can make that be the default, but I'll allow overriding it on the
command line.
> 2) Do you have any thoughts on the frequency that this script
Heh. Yup.
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
___
unix mailing list
Since you're thinking of looking at my script, here's a cleaned up
version. It makes it a little more obvious where to put one's
commands.
I call it "watch_usb_audio".
Code:
#!/bin/sh
exec >/home/tc/watch_usb_audio.log 2>&1
audiodev=$1
usage()
{
chill wrote:
>
> More good advice, thank you. But why is it a bad habit?
>
>
When a process receives a signal, it usually has a chance to do
something -- in fact, some signals are -only- used for "doing
something", and don't kill a process by default. They might be used to
tell the
chill wrote:
> Thanks for taking a look in that much detail. I'd love to agree with
> your final statement, but I've been very careful to make sure that the
> pidfile and the process stay in sync. My current test script avoids the
> init.d script altogether - it starts Squeezelite manually
One more possible gotcha with the init.d script:
run the start script, using sudo.
run the stop script, without sudo.
the pid file is now gone, but the squeezelite processes are still
there.
run the start script again, using sudo.
the script doesn't see a pidfile, so it starts a new
kill (from within ash) and /bin/kill (linked to busybox) are the same
program, almost. The version in ash has to first handle job ids ("kill
%2"), but then the common code is called. start-stop-daemon doesn't
invoke a kill program at all. Like any reasonable program, it simply
invokes the
Greg Erskine wrote:
> I notice Paul has installed the gawk/awk extension, probably gnu?. You
> have to be careful not to develop code on requires the use of the full
> blown version of the command without handling the installation of the
> extension.
>
> We have been caught before installing
chill wrote:
> Thanks again - very instructive, and it gives me something to look into
> tomorrow. I know that the path available to a script called by udev is
> indeed rather shorter than the one available under a user shell (i'll
> post it again tomorrow). But does this make a difference if
> For instance, awk --help reports 'BusyBox v1.31.1 (2020-12-18 22:25:41
> EST)' when called as either awk or /usr/bin/awk, whereas '/bin/echo
> --help' reports 'BusyBox v1.31.1 (2020-12-18 22:25:41 EST)' but without
> the path it simply echoes '--help'. So I'm curious where the separate
>
chill wrote:
>
> Anyone know how I can check for these built-in commands from within a
> script? What makes them 'built-in' - is it some default shell
> configuration? Could I manually load that configuration at the start of
> the script, so that even if these built-in commands aren't
Gotcha -- thanks. Not a worry for me, but nice to know in case I ever
hit it.
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
Is there a reason to want squeezelite stopped explicitly? Perhaps I
missed something in one of the preceding pages about that. (I'm
wondering if I should be doing it.)
If you did want to stop squeezelite explicitly, you might want to wait a
bit before doing so (perhaps just move the sleep to
Well, kill is an ash builtin, so without the full path, that's what
you're getting -- but that alone doesn't explain why it doesn't do its
job. (It's unlikely to be an internal ash problem in any case -- ash is
a very good shell.)
And as an aside: an old trick for keeping grep from returning
Whoa, this is fast-moving thread! I thought I was all caught up, and
suddenly there are another dozen messages! :-)
I'm pretty impressed by chill's script. Nice work. Keeping track of
all that statefulness, via multiple entry points to the script, is
tricky. The self-installation is a nice
Thanks -- last time I tried to get something from the tinycore repo I
had trouble finding a download link. I think I was successful
eventually, though -- oh, I remember, I had to go to a mirror -- I'll
try that. Thanks!
paul (a different one.)
I have a program that I've been running for years on various systems
which, when built on picoreplayer, surprised me with a segfault. I went
looking for gdb, and ... was surprised again. :-) Is gdb hidden in
some unexpected extension?
My system version is: piCorePlayer v7.0.0 | www
paul- wrote:
> That is the right place to do it. The backup process stores ownership
> in the backup file.and restores ownership during boot.
Thanks. The other part of my question is: does the .filetool.lst file
get overwritten on an upgrade? I guess I'll find out someday, but
As mentioned in my previous post, I've modified /opt/.filetool.lst in
order get the contents of /root backed up in mybackup.tgz.
Is this "safe" to do? will .filetool.lst get overwritten during an
upgrade without me knowing about it? If so, is there another way to add
files to the backup?
> On 2/24/2021 1:43 PM, paul- wrote:
> > pgf wrote:
> > [... wants to let two audio sources use pCP's output at a time...]
> >>
> > Squeezelite on pCP directly accesses alsa. Only one process can
> access
> > the alsa device at time, so you will need to
I'd like to try an extension that's available for TCL, but not listed as
available for pCP.
Is there a way to configure pCP to access a TCL extension repo?
Specifically, I'd like to install pulseaudio. I currently run about
half a dozen CHIP ("$9 computer") boards around the house -- they run
There's a typo in the help for setting an alternate MAC address for
squeezelite. The term "overwrite" is used -- I'm sure that what was
meant was "override". Clearly this config doesn't actually overwrite a
system MAC address, which would make the option a little scarier than it
actually is.
mherger wrote:
is there a low-volume release announcement mailing list? if updates
aren't automatic via repository, i'm afraid i might forget to check
for
new LMS releases for a very long time.
We have added an update checker to LMS a long time ago. But it's
disabled for Linux, as
is there a low-volume release announcement mailing list? if updates
aren't automatic via repository, i'm afraid i might forget to check for
new LMS releases for a very long time.
paul
pgf's Profile:
40 matches
Mail list logo
