lirc-list

Re: Forward LIRC from one machine to another via UDP over the network?

[Sean Y. <se...@me...>]

On Sun, Jun 08, 2025 at 10:41:52AM -0400, Paul Fox wrote:
> sean wrote:
>  > On Sun, Jun 08, 2025 at 06:56:39AM -0400, Paul Fox wrote:
>  > > sean wrote:
>  > >  > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
>  > >  > > patrick wrote:
>  > >  > >  >    I cobbled together this command on the RPi, hoping it would send the IR
>  > >  > >  >    signals to the MythTV computer in the same way the HDHR did but it doesn't
>  > >  > >  >    seem to be working.  I'm running irw on the 192.168.1.2 computer but it's
>  > >  > >  >    not receiving any signals.
>  > >  > >  > 
>  > >  > >  >    /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
>  > >  > >  >    udp-datagram:[1]192.168.1.2:5000,broadcast
>  > >  > >  > 
>  > >  > >  >    I'm hoping someone else has done this or has experience with it and could
>  > >  > >  >    offer me some assistance please.
>  > >  > > 
>  > >  > > Unless something has changed recently (and I doubt it), irtext2udp
>  > >  > > is broken, because it matches the documentation of the UDP protocol, which
>  > >  > > is also broken.  I submitted patches for these issues in March 2022:
>  > >  > >     https://sourceforge.net/p/lirc/tickets/370/
>  > >  > > I also sent mail to the (this) list about it at the same time -- I'm sure
>  > >  > > it's in the archives.  So that's probably at least part of your problem.
>  > >  > 
>  > >  > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
>  > >  > than making everything compatible with something that is clearly a bug.
>  > >  > 
>  > > 
>  > > No, I don't think you can do that.  You're changing an existing
>  > > protocol.  There is code out in the wild that's decades old at this
>  > > point, which depends on the current behavior.  (I know, I wrote some:
>  > > https://sourceforge.net/projects/airboard-ir/ )
>  > > 
>  > > If your patch were the right thing, I would have submitted it initially.
>  > > 
>  > > As it stands now, as soon as a new release a lirc makes it's way to
>  > > debian, half the devices in my house, and likely other peoples', will
>  > > stop working.
>  > 
>  > The lirc source tree contains two implementations of the udp protocol, one
>  > uses high bit set for pulse, the other space. The documentation says high
>  > bit set for pulse, and this also makes more sense. One or the other has to
>  > fixed.
> 
> Can you point me at the other implementation?  I didn't know there
> were two.   Sigh.

So the udp protocol is implemented by irtext2udp and plugins/udp.c. It is
also documented in various places, which is pretty unambiguous that a set
bit means pulse.

If we fix irtext2udp, that breaks the users of irtext2udp, however that might
be.

If we fix plugins/udp.c, then that breaks those users.

Either way you're breaking something for someone. Might as well do the right
think and implement the protocol as it is documented.


Sean

Re: Forward LIRC from one machine to another via UDP over the network?

[Paul F. <pg...@fo...>]

sean wrote:
 > On Sun, Jun 08, 2025 at 06:56:39AM -0400, Paul Fox wrote:
 > > sean wrote:
 > >  > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
 > >  > > patrick wrote:
 > >  > >  >    I cobbled together this command on the RPi, hoping it would send the IR
 > >  > >  >    signals to the MythTV computer in the same way the HDHR did but it doesn't
 > >  > >  >    seem to be working.  I'm running irw on the 192.168.1.2 computer but it's
 > >  > >  >    not receiving any signals.
 > >  > >  > 
 > >  > >  >    /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
 > >  > >  >    udp-datagram:[1]192.168.1.2:5000,broadcast
 > >  > >  > 
 > >  > >  >    I'm hoping someone else has done this or has experience with it and could
 > >  > >  >    offer me some assistance please.
 > >  > > 
 > >  > > Unless something has changed recently (and I doubt it), irtext2udp
 > >  > > is broken, because it matches the documentation of the UDP protocol, which
 > >  > > is also broken.  I submitted patches for these issues in March 2022:
 > >  > >     https://sourceforge.net/p/lirc/tickets/370/
 > >  > > I also sent mail to the (this) list about it at the same time -- I'm sure
 > >  > > it's in the archives.  So that's probably at least part of your problem.
 > >  > 
 > >  > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
 > >  > than making everything compatible with something that is clearly a bug.
 > >  > 
 > > 
 > > No, I don't think you can do that.  You're changing an existing
 > > protocol.  There is code out in the wild that's decades old at this
 > > point, which depends on the current behavior.  (I know, I wrote some:
 > > https://sourceforge.net/projects/airboard-ir/ )
 > > 
 > > If your patch were the right thing, I would have submitted it initially.
 > > 
 > > As it stands now, as soon as a new release a lirc makes it's way to
 > > debian, half the devices in my house, and likely other peoples', will
 > > stop working.
 > 
 > The lirc source tree contains two implementations of the udp protocol, one
 > uses high bit set for pulse, the other space. The documentation says high
 > bit set for pulse, and this also makes more sense. One or the other has to
 > fixed.

Can you point me at the other implementation?  I didn't know there
were two.   Sigh.


=----------------------
paul fox, pg...@fo... (arlington, ma, where it's 69.1 degrees)

Re: Forward LIRC from one machine to another via UDP over the network?

[Sean Y. <se...@me...>]

On Sun, Jun 08, 2025 at 06:56:39AM -0400, Paul Fox wrote:
> sean wrote:
>  > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
>  > > patrick wrote:
>  > >  >    I cobbled together this command on the RPi, hoping it would send the IR
>  > >  >    signals to the MythTV computer in the same way the HDHR did but it doesn't
>  > >  >    seem to be working.  I'm running irw on the 192.168.1.2 computer but it's
>  > >  >    not receiving any signals.
>  > >  > 
>  > >  >    /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
>  > >  >    udp-datagram:[1]192.168.1.2:5000,broadcast
>  > >  > 
>  > >  >    I'm hoping someone else has done this or has experience with it and could
>  > >  >    offer me some assistance please.
>  > > 
>  > > Unless something has changed recently (and I doubt it), irtext2udp
>  > > is broken, because it matches the documentation of the UDP protocol, which
>  > > is also broken.  I submitted patches for these issues in March 2022:
>  > >     https://sourceforge.net/p/lirc/tickets/370/
>  > > I also sent mail to the (this) list about it at the same time -- I'm sure
>  > > it's in the archives.  So that's probably at least part of your problem.
>  > 
>  > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
>  > than making everything compatible with something that is clearly a bug.
>  > 
> 
> No, I don't think you can do that.  You're changing an existing
> protocol.  There is code out in the wild that's decades old at this
> point, which depends on the current behavior.  (I know, I wrote some:
> https://sourceforge.net/projects/airboard-ir/ )
> 
> If your patch were the right thing, I would have submitted it initially.
> 
> As it stands now, as soon as a new release a lirc makes it's way to
> debian, half the devices in my house, and likely other peoples', will
> stop working.

The lirc source tree contains two implementations of the udp protocol, one
uses high bit set for pulse, the other space. The documentation says high
bit set for pulse, and this also makes more sense. One or the other has to
fixed.


Sean

Re: Forward LIRC from one machine to another via UDP over the network?

[Paul F. <pg...@fo...>]

sean wrote:
 > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
 > > patrick wrote:
 > >  >    I cobbled together this command on the RPi, hoping it would send the IR
 > >  >    signals to the MythTV computer in the same way the HDHR did but it doesn't
 > >  >    seem to be working.  I'm running irw on the 192.168.1.2 computer but it's
 > >  >    not receiving any signals.
 > >  > 
 > >  >    /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
 > >  >    udp-datagram:[1]192.168.1.2:5000,broadcast
 > >  > 
 > >  >    I'm hoping someone else has done this or has experience with it and could
 > >  >    offer me some assistance please.
 > > 
 > > Unless something has changed recently (and I doubt it), irtext2udp
 > > is broken, because it matches the documentation of the UDP protocol, which
 > > is also broken.  I submitted patches for these issues in March 2022:
 > >     https://sourceforge.net/p/lirc/tickets/370/
 > > I also sent mail to the (this) list about it at the same time -- I'm sure
 > > it's in the archives.  So that's probably at least part of your problem.
 > 
 > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
 > than making everything compatible with something that is clearly a bug.
 > 

No, I don't think you can do that.  You're changing an existing
protocol.  There is code out in the wild that's decades old at this
point, which depends on the current behavior.  (I know, I wrote some:
https://sourceforge.net/projects/airboard-ir/ )

If your patch were the right thing, I would have submitted it initially.

As it stands now, as soon as a new release a lirc makes it's way to
debian, half the devices in my house, and likely other peoples', will
stop working.

You can argue that the code is buggy (and I might agree), but you
can't fix it there, without causing more breakage.

paul
=----------------------
paul fox, pg...@fo... (arlington, ma, where it's 59.4 degrees)

Re: Forward LIRC from one machine to another via UDP over the network?

[Sean Y. <se...@me...>]

On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
> patrick wrote:
>  >    I cobbled together this command on the RPi, hoping it would send the IR
>  >    signals to the MythTV computer in the same way the HDHR did but it doesn't
>  >    seem to be working.  I'm running irw on the 192.168.1.2 computer but it's
>  >    not receiving any signals.
>  > 
>  >    /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
>  >    udp-datagram:[1]192.168.1.2:5000,broadcast
>  > 
>  >    I'm hoping someone else has done this or has experience with it and could
>  >    offer me some assistance please.
> 
> Unless something has changed recently (and I doubt it), irtext2udp
> is broken, because it matches the documentation of the UDP protocol, which
> is also broken.  I submitted patches for these issues in March 2022:
>     https://sourceforge.net/p/lirc/tickets/370/
> I also sent mail to the (this) list about it at the same time -- I'm sure
> it's in the archives.  So that's probably at least part of your problem.

I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
than making everything compatible with something that is clearly a bug.


Sean

Re: Forward LIRC from one machine to another via UDP over the network?

[Paul F. <pg...@fo...>]

patrick wrote:
 >    I cobbled together this command on the RPi, hoping it would send the IR
 >    signals to the MythTV computer in the same way the HDHR did but it doesn't
 >    seem to be working.  I'm running irw on the 192.168.1.2 computer but it's
 >    not receiving any signals.
 > 
 >    /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
 >    udp-datagram:[1]192.168.1.2:5000,broadcast
 > 
 >    I'm hoping someone else has done this or has experience with it and could
 >    offer me some assistance please.

Unless something has changed recently (and I doubt it), irtext2udp
is broken, because it matches the documentation of the UDP protocol, which
is also broken.  I submitted patches for these issues in March 2022:
    https://sourceforge.net/p/lirc/tickets/370/
I also sent mail to the (this) list about it at the same time -- I'm sure
it's in the archives.  So that's probably at least part of your problem.

For various reasons (mostly historical, but also having to do with my
network topology), I don't do lircd processing on the raspberry pi boxes
that are scattered around the house, each with an IR receiver.  Instead,
I forward the IR to a central server, where there's an instance of
lircd running for every client.  Since UDP can't make it through
my firewall, I send it over tcp, through an ssh tunnel, and convert
back to UDP at the destination.

For all of those reasons, I don't use irtext2udp.  I use my own script
(attached), which takes mode2 format and converts it to the UDP
format, and sends it to a tcp port.  You'll see that it sends to a port
on "localhost" -- that's because it's actually being forwarded across
an ssh tunnel.

On the receiving end, I have a listener that gets data from the other end
of the ssh tunnel.  The meat of it is this line:
   socat -u tcp4-listen:88${octet},reuseaddr,fork UDP:localhost:87${destoctet}
The 88xx address is what the ssh server delivers to, and the 87xx
address is the appropriate lircd daemon.

Hope some part of this helps.

paul
=----------------------
paul fox, pg...@fo... (arlington, ma, where it's 59.2 degrees)

Forward LIRC from one machine to another via UDP over the network?

[Patrick K. <kir...@gm...>]

Hello,

My Silicondust HDHomeRun DUAL (Model: HDHR-US) ATSC tuner that I was using
for over a decade to receive and send IR signals to my MythTV box via UDP
(port 5000) has stopped working.

I have a Raspberry Pi in the same TV room that has a working IR receiver on
it so I was hoping to reproduce the function of the HDHomeRun DUAL's IR
receiver using the Raspberry Pi.

I cobbled together this command on the RPi, hoping it would send the IR
signals to the MythTV computer in the same way the HDHR did but it doesn't
seem to be working.  I'm running irw on the 192.168.1.2 computer but it's
not receiving any signals.

/usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat - udp-datagram:
192.168.1.2:5000,broadcast

I'm hoping someone else has done this or has experience with it and could
offer me some assistance please.

Thanks

Re: 12 V for home-brew IR receiver

[Eduard R. <ere...@gm...>]

> I would suggest using a 7809 which drops the voltage to 9V. Someone else
> suggested a 7805, and that's not what you want because its output
> voltage is 5V which falls far short of the minimum of 8V that you cite.

No, I didn't write what output voltage I need, and certainly not that I
need 8 V at the output. But now I write that I need 5 V as the signal level.

I connect the DCD line to the Arduino Mega 2560 and use the IRremote
library.

And in reality, I don't even know which voltage regulator is used in my
circuit. The circuit is built into a DE-9F connector that I bought 20
years ago as LIRC-compatible home-brew IR-receiver. I used it for a long
time on the serial port of multiple mainboards. I can't open it without
cutting the heat shrink tubing. And that's why I'm not opening it.

Everything I know I read here: https://lirc.org/receivers.html
It is written there:
"For most standard PC serial ports this will be approximately 10V. IC2
will convert the input voltage to exactly 5V. ... So you should make
sure that your serial port delivers at least 8V of output voltage."

I need exactly 5 V for Arduino Mega 2560. And I trust that my
LIRC-compatible home-brew IR-receiver converts the input voltage to 5 V
and I get 5 V as signal level for Arduino Mega 2560. I don't have an
oscilloscope to check the signal level. I tested my LIRC-compatible
home-brew IR-Receiverwith 12 V supply voltage. It works very well with
RC5 remote control and neither IR-receivernor Arduinobroke.

Re: 12 V for home-brew IR receiver

[Jan C. <jan...@gm...>]

On 24/03/2025 20:12, Eduard Refinius via LIRC-list wrote:
> Hello.
>
> I have a home-brew IR receiver as described on
> https://lirc.org/receivers.html
>
> I've read, that supply voltage range 8 V .. 10 V is ok for this circuit.
> Is it ok for the voltage regulator to be supplied by 12 V or is it too
> much? I don't want to damage the IR receiver.
>
>
I would suggest using a 7809 which drops the voltage to 9V. Someone else
suggested a 7805, and that's not what you want because its output
voltage is 5V which falls far short of the minimum of 8V that you cite.

Re: 12 V for home-brew IR receiver

[Umar D. <um...@gm...>]

The 7805 voltage regulator drops any supplied input voltage to 5V. The 7805
has a maximum voltage of around 25V. The drawback of using higher voltages
is that the 7805 needs to drop/lower the voltage more, it does so through
heat. The higher the voltage you use the more heat will need to be
dissipated by the 7805. However, the heat generated is also proportional to
the amount of current or power being used, and in this case the IR diode
draws a small amount. As such I would say 12V is safe to use, worst case
add a small heatsink to the 7805 Regulator.

On Tue, Mar 25, 2025 at 12:26 PM Eduard Refinius via LIRC-list <
lir...@li...> wrote:

> Hello.
>
> I have a home-brew IR receiver as described on
> https://lirc.org/receivers.html
>
> I've read, that supply voltage range 8 V .. 10 V is ok for this circuit.
> Is it ok for the voltage regulator to be supplied by 12 V or is it too
> much? I don't want to damage the IR receiver.
>
>
>

12 V for home-brew IR receiver

[Eduard R. <ere...@gm...>]

Hello.

I have a home-brew IR receiver as described on
https://lirc.org/receivers.html

I've read, that supply voltage range 8 V .. 10 V is ok for this circuit.
Is it ok for the voltage regulator to be supplied by 12 V or is it too
much? I don't want to damage the IR receiver.

Using LIRC with Python

[Nico B. <nca...@ic...>]

Hi there, maybe answer to my problem is allready somewhere on the 
internet, if so please point me.

I use Lirc on my Raspberry Pi, installed with sudo apt install lirc. So 
far so good.
No I want to make a python script to interact with my OS "Raspberry Pi 
OS with desktop" 64 bit kernel 6.6. Based on Debian Bookworm. Python 3.1.

Now my python was making problems about all kind of rights on files. So 
the project became a mess and i have made a new MicroSD card.
Starting all over I have looked into the way pip i working these days. 
Virtual envirements.
So, now the Lirc, global wide installed isn't in reach of python. So I 
installed lirc with pip install lirc. Now no more problems finding Lirc.

But here is the problem, in the pip version of lirc there is no 
RawConnections to use. So, how to solve this?


Thx, in advance, Pit

Re: Send IR without writing them to the config file - How to?

[Bengt M. <bu...@be...>]

On 9/16/24 10:41, Sean Young wrote:
> On Sun, Sep 15, 2024 at 01:48:19PM +0200, Mariusz Ferdyn wrote:
>> The captured codes are:
>>
>>
>> mf@pi1:~ $ mode2 -H default -d /dev/lirc0
>> Using driver default on device /dev/lirc0
>> Trying device: /dev/lirc0
>> Using device: /dev/lirc0
>> pulse 8985
>> space 4468
>> pulse 617
>> space 1651
>> pulse 601
>> space 1652
>> pulse 604
>> space 499
> -snip-
>
> This looks good, this is probably the nec protocol.

Actually, the timing is that of the NEC protocol, but the payload is 104
bytes, instead of 32 for NEC. (Air conditioning?) The second signal can
be described in the IRP notation as

{568,msb}<1,-1|1,-3>(16,-8,A:104,1,-299m){A=0xc3fe070006000400000000a2e7}

Returning to your first question:


 > I would like to send these ad-hock mode without writing them to
the config file etc. How to do it?


Lirc is not intended for this use case. I once submitted a patch to the
then-maintainer Christoph Bartelmus, who was vehemently against it,
meaning that it is cleaner if data bases reside on the server. See
http://www.harctoolbox.org/lirc_ccf.html, but note that article is not
up-to-data any longer.


Have a look at IrScrutinizer (http://www.harctoolbox.org/lirc_ccf.html);
possibly you can use it for your purpose?


Bengt

Re: Send IR without writing them to the config file - How to?

[Sean Y. <se...@me...>]

On Sun, Sep 15, 2024 at 01:48:19PM +0200, Mariusz Ferdyn wrote:
> On 9/15/2024 10:12 AM, Sean Young wrote:
> > Hi,
> > 
> > On Sat, Sep 14, 2024 at 10:43:35PM +0200, Mariusz Ferdyn wrote:
> > > Using command mode2 -d /dev/lirc0 I received:
> > > 
> > > 
> > > Using driver devinput on device /dev/lirc0
> > > Trying device: /dev/lirc0
> > > Using device: /dev/lirc0
> > > code: 0xfd695000a94d50001f23000182110000
> > > code: 0x54020001740600005b02000182060000
> > > code: 0x4f0200010302000063020001ff010000
> > > code: 0x64020001030200005c0200010a020000
> > > code: 0x5d020001740600005902000171060000
> > > Partial read 4 bytes on /dev/lirc0
> > I think you need to run `mode2 -H default -d /dev/lirc0`, driver devinput
> > is not the right one.
> > 
> > > and now I would like to send these ad-hock mode without writing them to the
> > > config file etc. How to do it?
> > Please get the right codes first.
> > 
> > 
> > Sean
> > 
> The captured codes are:
> 
> 
> mf@pi1:~ $ mode2 -H default -d /dev/lirc0
> Using driver default on device /dev/lirc0
> Trying device: /dev/lirc0
> Using device: /dev/lirc0
> pulse 8985
> space 4468
> pulse 617
> space 1651
> pulse 601
> space 1652
> pulse 604
> space 499

-snip-

This looks good, this is probably the nec protocol.

Put all the pulse/space lines into a file. Then you can send it with

ir-ctl -s file

I don't know that this can be done easily with the lirc tooling. Maybe it
can be put into lircd.conf raw_codes remote definition, but this might be
too heavyweight for what you're looking for.


Sean

Re: Send IR without writing them to the config file - How to?

[Mariusz F. <mf...@fa...>]

On 9/15/2024 10:12 AM, Sean Young wrote:
> Hi,
>
> On Sat, Sep 14, 2024 at 10:43:35PM +0200, Mariusz Ferdyn wrote:
>> Using command mode2 -d /dev/lirc0 I received:
>>
>>
>> Using driver devinput on device /dev/lirc0
>> Trying device: /dev/lirc0
>> Using device: /dev/lirc0
>> code: 0xfd695000a94d50001f23000182110000
>> code: 0x54020001740600005b02000182060000
>> code: 0x4f0200010302000063020001ff010000
>> code: 0x64020001030200005c0200010a020000
>> code: 0x5d020001740600005902000171060000
>> Partial read 4 bytes on /dev/lirc0
> I think you need to run `mode2 -H default -d /dev/lirc0`, driver devinput
> is not the right one.
>
>> and now I would like to send these ad-hock mode without writing them to the
>> config file etc. How to do it?
> Please get the right codes first.
>
>
> Sean
>
The captured codes are:


mf@pi1:~ $ mode2 -H default -d /dev/lirc0
Using driver default on device /dev/lirc0
Trying device: /dev/lirc0
Using device: /dev/lirc0
pulse 8985
space 4468
pulse 617
space 1651
pulse 601
space 1652
pulse 604
space 499
pulse 622
space 505
pulse 618
space 501
pulse 625
space 500
pulse 623
space 1652
pulse 580
space 1676
pulse 599
space 1652
pulse 601
space 1663
pulse 601
space 1649
pulse 567
space 1672
pulse 602
space 1651
pulse 601
space 1667
pulse 587
space 1653
pulse 600
space 500
pulse 626
space 498
pulse 601
space 523
pulse 599
space 525
pulse 600
space 524
pulse 624
space 500
pulse 620
space 1658
pulse 599
space 1652
pulse 576
space 1676
pulse 578
space 525
pulse 624
space 503
pulse 597
space 525
pulse 610
space 525
pulse 597
space 521
pulse 623
space 503
pulse 602
space 515
pulse 608
space 522
pulse 598
space 517
pulse 619
space 501
pulse 601
space 522
pulse 599
space 525
pulse 607
space 519
pulse 623
space 1661
pulse 568
space 1677
pulse 598
space 500
pulse 599
space 525
pulse 599
space 547
pulse 585
space 530
pulse 625
space 490
pulse 596
space 527
pulse 598
space 523
pulse 600
space 524
pulse 600
space 524
pulse 600
space 524
pulse 600
space 524
pulse 601
space 525
pulse 606
space 527
pulse 599
space 523
pulse 597
space 1683
pulse 576
space 518
pulse 594
space 578
pulse 553
space 517
pulse 599
space 524
pulse 603
space 523
pulse 599
space 529
pulse 595
space 525
pulse 598
space 525
pulse 600
space 525
pulse 598
space 525
pulse 600
space 524
pulse 600
space 524
pulse 597
space 526
pulse 577
space 549
pulse 576
space 555
pulse 570
space 548
pulse 599
space 526
pulse 599
space 526
pulse 603
space 523
pulse 598
space 524
pulse 600
space 523
pulse 602
space 522
pulse 602
space 524
pulse 609
space 1681
pulse 570
space 523
pulse 629
space 499
pulse 609
space 508
pulse 601
space 521
pulse 678
space 450
pulse 604
space 516
pulse 596
space 526
pulse 599
space 523
pulse 601
space 528
pulse 600
space 512
pulse 598
space 1675
pulse 584
space 526
pulse 591
space 1681
pulse 573
space 527
pulse 611
space 534
pulse 574
space 528
pulse 595
space 1678
pulse 575
space 550
pulse 575
space 1682
pulse 572
space 1678
pulse 587
space 1679
pulse 573
space 542
pulse 581
space 545
pulse 577
space 544
pulse 572
space 554
pulse 569
space 558
pulse 571
timeout 21604
^C
mf@pi1:~ $ mode2 -H default -d /dev/lirc0
Using driver default on device /dev/lirc0
Trying device: /dev/lirc0
Using device: /dev/lirc0
pulse 9000
space 4463
pulse 601
space 1670
pulse 601
space 1653
pulse 588
space 515
pulse 626
space 499
pulse 622
space 502
pulse 624
space 502
pulse 623
space 1664
pulse 601
space 1653
pulse 588
space 1659
pulse 592
space 1652
pulse 600
space 1669
pulse 582
space 1661
pulse 598
space 1654
pulse 599
space 1653
pulse 600
space 1653
pulse 579
space 531
pulse 616
space 500
pulse 623
space 501
pulse 623
space 501
pulse 624
space 501
pulse 602
space 522
pulse 623
space 1636
pulse 619
space 1642
pulse 615
space 1641
pulse 617
space 495
pulse 618
space 499
pulse 625
space 503
pulse 625
space 504
pulse 616
space 499
pulse 624
space 501
pulse 623
space 517
pulse 608
space 501
pulse 623
space 501
pulse 601
space 525
pulse 602
space 519
pulse 624
space 500
pulse 624
space 500
pulse 602
space 1653
pulse 624
space 1635
pulse 617
space 500
pulse 623
space 501
pulse 623
space 501
pulse 624
space 502
pulse 601
space 524
pulse 611
space 514
pulse 601
space 527
pulse 624
space 518
pulse 600
space 526
pulse 584
space 523
pulse 601
space 528
pulse 602
space 515
pulse 598
space 524
pulse 604
space 548
pulse 577
space 1653
pulse 609
space 512
pulse 590
space 523
pulse 600
space 525
pulse 601
space 523
pulse 601
space 531
pulse 604
space 515
pulse 599
space 527
pulse 599
space 523
pulse 599
space 526
pulse 600
space 525
pulse 599
space 525
pulse 599
space 526
pulse 579
space 546
pulse 598
space 526
pulse 600
space 523
pulse 600
space 526
pulse 600
space 524
pulse 601
space 531
pulse 607
space 526
pulse 605
space 511
pulse 598
space 523
pulse 606
space 519
pulse 603
space 523
pulse 594
space 522
pulse 599
space 525
pulse 634
space 509
pulse 585
space 531
pulse 583
space 523
pulse 600
space 523
pulse 600
space 524
pulse 600
space 525
pulse 600
space 526
pulse 599
space 536
pulse 619
space 497
pulse 597
space 1666
pulse 587
space 526
pulse 598
space 1658
pulse 596
space 526
pulse 598
space 529
pulse 596
space 528
pulse 597
space 1659
pulse 593
space 539
pulse 591
space 1682
pulse 579
space 1678
pulse 561
space 1679
pulse 572
space 536
pulse 595
space 524
pulse 609
space 1668
pulse 569
space 1683
pulse 569
space 1683
pulse 571
timeout 13141
^C
mf@pi1:~ $

Re: Send IR without writing them to the config file - How to?

[Sean Y. <se...@me...>]

Hi,

On Sat, Sep 14, 2024 at 10:43:35PM +0200, Mariusz Ferdyn wrote:
> Using command mode2 -d /dev/lirc0 I received:
> 
> 
> Using driver devinput on device /dev/lirc0
> Trying device: /dev/lirc0
> Using device: /dev/lirc0
> code: 0xfd695000a94d50001f23000182110000
> code: 0x54020001740600005b02000182060000
> code: 0x4f0200010302000063020001ff010000
> code: 0x64020001030200005c0200010a020000
> code: 0x5d020001740600005902000171060000
> Partial read 4 bytes on /dev/lirc0

I think you need to run `mode2 -H default -d /dev/lirc0`, driver devinput
is not the right one.

> and now I would like to send these ad-hock mode without writing them to the
> config file etc. How to do it?

Please get the right codes first.


Sean

Send IR without writing them to the config file - How to?

[Mariusz F. <mf...@fa...>]

Using command mode2 -d /dev/lirc0 I received:


Using driver devinput on device /dev/lirc0
Trying device: /dev/lirc0
Using device: /dev/lirc0
code: 0xfd695000a94d50001f23000182110000
code: 0x54020001740600005b02000182060000
code: 0x4f0200010302000063020001ff010000
code: 0x64020001030200005c0200010a020000
code: 0x5d020001740600005902000171060000
Partial read 4 bytes on /dev/lirc0


and now I would like to send these ad-hock mode without writing them to 
the config file etc. How to do it?

Mariusz Ferdyn

Trying to generate working config for air conditioner remote

[Sahbi <sa...@ze...>]

I'm trying to use irrecord (with -f option) to generate a config file, 
which has always worked fine but seems to have some troubles with this 
particular remote. The exact model of the AC is Eurom PAC 29R. Unlike 
many other AC remotes this one does not seem to include its own state 
(e.g. current temperature setting). It has no little display on it to 
show any current settings, so if people can't even see any state then 
it's probably safe to assume there is no state. I'm guessing because the 
unit has physical controls as well, so communicating changes from that 
end to the remote would be overly complex (and unreliable, if the remote 
is out of "sight").

Anyway, I'm using the "default" driver and I think the problem is 
related to errors I get during recording:

 > Something went wrong: Signal length is 0
 > That's weird because the signal length must be odd!

The signal length varies a lot too:
 > Something went wrong: Signal length is 192
 > Something went wrong: Signal length is 180
 > Something went wrong: Signal length is 172
 > Something went wrong: Signal length is 176
 > Something went wrong: Signal length is 138
 > Something went wrong: Signal length is 86

If I keep holding down the button long enough it will eventually 
succeed, but I think it's pretty much guaranteed to be garbage at this 
point anyway? Note that releasing the button once the error pops up and 
holding it down "fresh" will cause it to keep throwing errors, unless of 
course the next attempt proceeds too fast for me to even register the 
error. It doesn't seem to matter if I hold the remote right in front of 
the receiver or about 30-50 cm away, sending codes from the resulting 
config will always be ignored by the unit (but the IR LED does light 
up). I've verified that sending other IR codes at least works correctly; 
I have other configs and sending any code makes the relevant device 
respond immediately. I even tried the devinput driver (and without -f) 
but that just generates the code 0x0 for any and all buttons.

I'm running all this off a Raspberry Pi by the way.

~Sahbi

Re: Transfer lirc setup on CentOS-7

[Christopher S. H. <ch...@vi...>]

On Tue, Jul 16, 2024 at 02:55:05PM -0400, Chris Hilton wrote:
> Let me start by saying thanks again to Bengt Martensson! With his help I was able to get
> things going with lirc, installed from packages on my Rocky-9 test box so I have a setup
> that works.
> 
> My problem:
> 
> I'm trying to get lirc running to change channels on my set-top box for MythTV. I've run
> mythtv for a while and my current setup is Myth-0.29 on CentOS-7. My Cable TV company has
> dropped support the the Scientific Atlanta settop box that I currently use with this
> installation. That's a problem because I use firewire to change channels. The box that
> replaces it doesn't respond to my firewire channel changing program. But I can change
> channels using Lirc. I know it works and that it works very well, from testing my setup on a
> new Rocky-9 box.
> 

Update:

I can send codes using the binary packages that shipped with Rocky-8. I still can't get IR
receiving to work in either rocky-8 or rocky-9. That's not a must have right now but It
would be nice for debugging later. I would still very much like to get this hardware working
with CentOS-7 at least for the next month but now I have a workaround...


-- Chris

-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Transfer lirc setup on CentOS-7

[Christopher S. H. <ch...@vi...>]

Let me start by saying thanks again to Bengt Martensson! With his help I was able to get
things going with lirc, installed from packages on my Rocky-9 test box so I have a setup
that works.

My problem:

I'm trying to get lirc running to change channels on my set-top box for MythTV. I've run
mythtv for a while and my current setup is Myth-0.29 on CentOS-7. My Cable TV company has
dropped support the the Scientific Atlanta settop box that I currently use with this
installation. That's a problem because I use firewire to change channels. The box that
replaces it doesn't respond to my firewire channel changing program. But I can change
channels using Lirc. I know it works and that it works very well, from testing my setup on a
new Rocky-9 box.

**My current problem is transfering the setup from my Rocky-9 test environment to my
CentOS-7 production environment.**

Making things work on Rocky was as easy as:

    # lircd --driver=ftdix --device "serial=D*******,output=2" --nodaemon

in one terminal window, then:

    # irsend SEND_ONCE new_samsung_set_top_box "KEY_POWER"

et voila, my cablebox turned on. Channel changes was as simple.

Unfortunately, this doesn't work on CentOS-7


My question:

**Is there something simple that I'm missing, or is the software installed from EPEL rpms
for lirc too old to easily support what I want to do?**


Details

I'm thinking that I'm the last person in the world using MythTV with a Hauppauge HD-PVR and
one of the only people in the world who's MythTV is in a rack in my basement rather than in
my entertainment center next to my television. That's making my testing very difficult.

My IR blaster is a "FTDI USB IR Blaster" purchased from here:

    https://www.irblaster.info/usb_blaster.html

My hardware is old enough to have an actual working serial port and I also have an old style
serial IR blaster. Getting either of them working would be enough to keep me going here.


Thank you

-- Chris



-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: LIRC / MythTV setup questions

[Christopher S. H. <ch...@vi...>]

On Sun, Jun 30, 2024 at 02:39:36PM -0400, Chris Hilton wrote:
> [ ...snip... ]
>  

Thanks again Bengt,


I moved the IR rig downstairs in front of my IR repeater in my main stereo. From there I
figured out that none of the commands I was sending were actually doing anything because I
was using the wrong output on my ftdi dongle. In the end the file you sent me did the
trick. It's working now.

-- Chris

-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: LIRC / MythTV setup questions

[Christopher S. H. <ch...@vi...>]

On Sun, Jun 30, 2024 at 06:58:43PM +0200, Bengt Martensson wrote:
> On 6/30/24 04:16, Christopher Sean Hilton wrote:
> > Hello,
> > 
> > It's become time to update my mythtv. This change is being driven by the fact that the
> > Scientific Atlanta 4250 set top box which my cable provider, Altice / Optimum, choose so
> > many years ago will no longer be supported sometime in August. My current setup doesn't
> > require lirc, I use firewire tochange channels but the new cable box, an Optimum branded
> > Samsung SMT-C5320 doesn't respond to the firewire like the SA4250.
> 
> I found the IR codes for Samsung SMT-C5320 on the Internet, and loaded it
> into IrScrutinizer. The protocol was identified as Panasonic_Old. With said
> program, I also generated a lirc.conf file, enclosed. (The frequency looks a
> bit uncommon, if it does not work, try with 38000) Hope this helps.
> 
> 
> [ ...snip... ]
 
Thanks Bengt,

I tried that file and I got no joy. I'm starting to believe that I have a problem somewhere
in my setup and that I'm actually not emitting any IR signals at all. But I don't have a way
to test that. As a result, I'm getting discouraged and I'm running out of ideas.

I've ordered an IR Receiver on the hope that I my original thesis is correct and that the
only issue is that I'm sending the wrong codes so my catv box isn't able to respond to
them. I'm hoping that getting the receiver will let me use `irrecord` to create a local
`SMT-C5320.lircd.conf` file which would hopefully allow me to change channels on this
(these) cable boxes so I can use it with mythtv.

One of my big concerns is that I saw a note on a TV forum list that very specifically called
out this box as it was issued from CableVision back in the day. It seems that they custom
ordered them from Samsung to respond to the same remote that they shipped. This single
remote could control either an SA42xx or this Samsung set top box. You could switch between
the two set top boxes with making any configuration change to the remote. That has me
thinking that these SMT-C5320s have been hacked to respond to a special set of codes.

-- Chris



> # IrScrutinizer parametric export
> #
> # Creating tool: IrScrutinizer version 2.4.2-SNAPSHOT
> # Creating user: bengt
> # Creating date: Sun Jun 30 18:44:44 CEST 2024
> # Encoding: WINDOWS-1252
> #
> # Manufacturer: Samsung
> # Model: SMT-C5320
> # Displayname: Samsung SMT-C5320
> # Device Class: cable
> # Remotename: 
> #
> 
> # Protocol name: Panasonic_Old
> begin remote
> 	name		Samsung_SMT-C5320-Panasonic_Old
> 	bits		22
> 	flags		SPACE_ENC
> 	eps		30
> 	aeps		100
> 	zero		833	833
> 	one		833	2499
> 	header		3332	3332
> 	ptrail		833
> 	gap		44000
> 	frequency	57600
> 	begin codes
> 		ASTERISK	0x000000000037E103
> 		CHANNEL_DOWN	0x000000000036F121
> 		CHANNEL_UP	0x0000000000377111
> 		CURSOR_DOWN	0x000000000037A10B
> 		CURSOR_ENTER	0x0000000000366133
> 		CURSOR_LEFT	0x000000000037810F
> 		CURSOR_RIGHT	0x0000000000364137
> 		CURSOR_UP	0x000000000036812F
> 		DIGIT_0	0x0000000000373119
> 		DIGIT_1	0x000000000036113D
> 		DIGIT_2	0x000000000037111D
> 		DIGIT_3	0x000000000036912D
> 		DIGIT_4	0x000000000037910D
> 		DIGIT_5	0x0000000000365135
> 		DIGIT_6	0x0000000000375115
> 		DIGIT_7	0x000000000036D125
> 		DIGIT_8	0x000000000037D105
> 		DIGIT_9	0x0000000000363139
> 		ENTER	0x000000000036B928
> 		EXIT	0x0000000000366932
> 		FAVORITE	0x000000000037F101
> 		FORMAT_SCROLL	0x000000000036B928
> 		FORWARD	0x000000000036293A
> 		FUNCTION_BLUE	0x000000000036193C
> 		FUNCTION_GREEN	0x00000000000F7E10
> 		FUNCTION_RED	0x000000000037191C
> 		FUNCTION_YELLOW	0x000000000037E902
> 		GUIDE	0x000000000036C127
> 		INFO	0x000000000036213B
> 		LIVE	0x000000000036B129
> 		MENU_DVR	0x000000000036C926
> 		MENU_MAIN	0x000000000036F920
> 		MENU_SETUP	0x0000000000373918
> 		PAUSE	0x0000000000374117
> 		PIP	0x000000000037B908
> 		PIP_CHANNEL_DOWN	0x000000000037F900
> 		PIP_CHANNEL_UP	0x000000000036E922
> 		PIP_POSITION	0x0000000000377910
> 		PIP_SWAP	0x0000000000367930
> 		PLAY	0x000000000037990C
> 		POWER_TOGGLE	0x000000000037C107
> 		PREVIOUS_CHANNEL	0x000000000036E123
> 		RECORD	0x0000000000375914
> 		REPLAY	0x000000000037C906
> 		REVERSE	0x000000000037291A
> 		STOP	0x0000000000365934
> 		VIDEO_SOURCE	0x0000000000376113
> 	end codes
> end remote



-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: LIRC / MythTV setup questions

[Bengt M. <bu...@be...>]

On 6/30/24 04:16, Christopher Sean Hilton wrote:
> Hello,
>
> It's become time to update my mythtv. This change is being driven by the fact that the
> Scientific Atlanta 4250 set top box which my cable provider, Altice / Optimum, choose so
> many years ago will no longer be supported sometime in August. My current setup doesn't
> require lirc, I use firewire tochange channels but the new cable box, an Optimum branded
> Samsung SMT-C5320 doesn't respond to the firewire like the SA4250.

I found the IR codes for Samsung SMT-C5320 on the Internet, and loaded 
it into IrScrutinizer. The protocol was identified as Panasonic_Old. 
With said program, I also generated a lirc.conf file, enclosed. (The 
frequency looks a bit uncommon, if it does not work, try with 38000) 
Hope this helps.


Greets,

Bengt

# IrScrutinizer parametric export
#
# Creating tool: IrScrutinizer version 2.4.2-SNAPSHOT
# Creating user: bengt
# Creating date: Sun Jun 30 18:44:44 CEST 2024
# Encoding: WINDOWS-1252
#
# Manufacturer: Samsung
# Model: SMT-C5320
# Displayname: Samsung SMT-C5320
# Device Class: cable
# Remotename:
#

# Protocol name: Panasonic_Old
begin remote
     name        Samsung_SMT-C5320-Panasonic_Old
     bits        22
     flags        SPACE_ENC
     eps        30
     aeps        100
     zero        833    833
     one        833    2499
     header        3332    3332
     ptrail        833
     gap        44000
     frequency    57600
     begin codes
         ASTERISK    0x000000000037E103
         CHANNEL_DOWN    0x000000000036F121
         CHANNEL_UP    0x0000000000377111
         CURSOR_DOWN    0x000000000037A10B
         CURSOR_ENTER    0x0000000000366133
         CURSOR_LEFT    0x000000000037810F
         CURSOR_RIGHT    0x0000000000364137
         CURSOR_UP    0x000000000036812F
         DIGIT_0    0x0000000000373119
         DIGIT_1    0x000000000036113D
         DIGIT_2    0x000000000037111D
         DIGIT_3    0x000000000036912D
         DIGIT_4    0x000000000037910D
         DIGIT_5    0x0000000000365135
         DIGIT_6    0x0000000000375115
         DIGIT_7    0x000000000036D125
         DIGIT_8    0x000000000037D105
         DIGIT_9    0x0000000000363139
         ENTER    0x000000000036B928
         EXIT    0x0000000000366932
         FAVORITE    0x000000000037F101
         FORMAT_SCROLL    0x000000000036B928
         FORWARD    0x000000000036293A
         FUNCTION_BLUE    0x000000000036193C
         FUNCTION_GREEN    0x00000000000F7E10
         FUNCTION_RED    0x000000000037191C
         FUNCTION_YELLOW    0x000000000037E902
         GUIDE    0x000000000036C127
         INFO    0x000000000036213B
         LIVE    0x000000000036B129
         MENU_DVR    0x000000000036C926
         MENU_MAIN    0x000000000036F920
         MENU_SETUP    0x0000000000373918
         PAUSE    0x0000000000374117
         PIP    0x000000000037B908
         PIP_CHANNEL_DOWN    0x000000000037F900
         PIP_CHANNEL_UP    0x000000000036E922
         PIP_POSITION    0x0000000000377910
         PIP_SWAP    0x0000000000367930
         PLAY    0x000000000037990C
         POWER_TOGGLE    0x000000000037C107
         PREVIOUS_CHANNEL    0x000000000036E123
         RECORD    0x0000000000375914
         REPLAY    0x000000000037C906
         REVERSE    0x000000000037291A
         STOP    0x0000000000365934
         VIDEO_SOURCE    0x0000000000376113
     end codes
end remote

LIRC / MythTV setup questions

[Christopher S. H. <ch...@vi...>]

Hello,

It's become time to update my mythtv. This change is being driven by the fact that the
Scientific Atlanta 4250 set top box which my cable provider, Altice / Optimum, choose so
many years ago will no longer be supported sometime in August. My current setup doesn't
require lirc, I use firewire tochange channels but the new cable box, an Optimum branded
Samsung SMT-C5320 doesn't respond to the firewire like the SA4250.

My equipment is an FTDI FT230X transmitter setup in lirc under Rocky Linux 9.

I've installed the following modules:

    libftdi-1.5-2.el9.aarch64

    lirc-libs-0.10.0-36.el9.aarch64
    lirc-core-0.10.0-36.el9.aarch64
    lirc-tools-gui-0.10.0-36.el9.aarch64
    lirc-drv-ftdi-0.10.0-36.el9.aarch64
    lirc-doc-0.10.0-36.el9.noarch
    lirc-config-0.10.0-36.el9.noarch

I'm running:

    # lircd --driver=ftdix --device "serial=D<serialno>,output=3"

to start lircd. I think everything is running okay. 

I'm at the stage of trying various remote modules to control the power and the channel on
the current cable box. I'm only getting one warning and I don't know if it's significant:

    ... lircd-0.10.0[18356]: Warning: Failed to set scheduling policy to SCHED_FIFO:
                             Operation not permitted Sending will not run with real-time
			     priority and you may suffer USB buffer underruns causing
			     corrupt IR signals


I'm hoping that I'm on the right track and that the problem that I have is that I'm just
using the wrong driver for the Samsung set top box. I do know that Optimum set these cable
boxes up to respond to the same remote control that they issued for their SA boxes like my
SA4250 so I suspect that my box needs custom code but I don't have a way to test that.

I think that my next steps are to:

1. Setup some sort of IR receiving capability so I can use `irrecord` to capture the codes
   that my remote is sending and create a new remote file?


------------------------------------------------------------

Does a proper remote file `xxx.lircd.conf` exist for this cable box and am I just missing
it?

Is the approach I outlined a good way to get to what I need?

Am I overlooking something else?

P.S. I do have a hauppauge HD-PVR, my capture device for MythTV. Would setting that up as a
capture device be a good plan or should I just find some simple, $20 or less IR receiver
that's support to save myself some trouble?


-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: Missing something basic no doubt

[Bengt M. <bu...@be...>]

Sorry for taking so long to answer.

On 5/1/24 16:37, James B Huber wrote:
> ok, see below....
>
> On Wed, 2024-05-01 at 14:26 +0200, Bengt Martensson wrote:
>> On 4/30/24 21:48, James B Huber wrote:
>>> Hardware is just fine...it's a USB device, move it to a rpi-4b, works
>>> fine....move it to my Linux Mint box, it works fine.


One thing to try: On all your machines, install IrScrutinizer
https://github.com/bengtmartensson/IrScrutinizer/releases/tag/Version-2.4.1,
then with the thing plugged in, open it as hardware -> /dev/lirc ->
Device /dev/lirc0, and compare the "detected properites" between the
working and non-working hosts. You can of course  also try to capture
from IrScrutinizer, but it will probably not work. You said that
transmitting works?


And, to repeat myself,

>>
>> Then it must be a problem with drivers/modules.... mode2
>> should, when a RC6 or MCE signal is fired, output mostly duration of
>> length 444 and 888 (+- 30%, say). For now, leave Lirc out of the equaton.


If still no clue, you have to go to driver/modules/Linux gurus. The
Linux media list may be an address. Please post a link here if you do
so.  Sean, are you here?


Greetings on the Star Wars day,

Bengt