After my OTGW project attracted a lot more interest than I ever expected, I decided to publish another device I made for my own use, which may also be useful for other people. It's an IR transmitter/receiver that interacts via MQTT, so it can be used by a home automation system for controlling equipment with an IR remote control.
The main difference with other IR transmitters currently available is the fact that new IR protocols can easily be added by providing their IRP specification. The IRP specification was created by John S. Fine. It provides a very compact way to exactly specify pretty much any IR signal ever invented.
While the device is built around commonly available components, it may be hard for an individual to have a circuit board made and obtain a front panel that allows IR signals to pass through. I have therefor once again found the Nodo shop willing to offer the device as a kit (Wemos D1 sold separately) that includes the PCB and enclosure.
Details can be found at https://espirp.tclcode.com/
ESPIRP project.
Moderator: hvxl
ESPIRP project.
Schelte
Re: ESPIRP project.
I am proud to announce the release of firmware 3.0 for the espirp. Users can update their devices by going to the status web page of their device, and clicking the "OTA upgrade" button. But before doing so, read the information below for a few incompatibilities with firmware version 2.x.
With firmware 3.0, the IR capabilities of the espirp are now completely driven by the installed IRP definitions. Transmitting IR signals was already based on IRP definitions. This is now also true for receiving IR signals. So the device is no longer limited to receiving only a fixed set of hard-coded IR signal families. This means that adding full support* for a new IR signal family is as simple as entering an IRP string on a built-in web page.
Receiving IR signals is now handled by decoders. Currently there are 8 decoders available. Each decoder can be configured to handle one IR protocol. It is expected that 8 decoders suffices for normal use. The reported signals can be narrowed down further by specifying a value for one or more variables of the IRP definition.
A change from firmware 2.x is that NEC1 and NEC2 signals are no longer reported as just NEC. Depending on which of the protocols has been assigned to one of the decoders, that protocol is reported. Since the first iteration of NEC1 and NEC2 signals are identical, a decoder configured for NEC1 will report a single iteration of a NEC2 signal. The reverse is also true. If it is important to distinguish the two protocols, a subsequent iteration must be checked (using receive full mode). A NEC1 decoder will only report subsequent iterations of a real NEC1 signal. The same is true for a NEC2 signal and a NEC2 decoder. Signals with so-called dittos (for example NEC1) are now reported (in receive full mode) with the full information, not simply with device 0, function 0.
When dealing with a unknown IR protocol, the espirp can be set to capture mode via the Interact web page. The pulse durations of received IR signals will then be reported. Clicking on a list of pulse durations will present a graphical representation of the signal. The signal is also compared against all installed IRP definitions. Any matches are listed.
Finally, some other improvements to the reception of IR signals have been made: Filtering of stray IR noise between repetitions of the signal has been added. This makes it less likely that a long button press will be reported as multiple presses. And the feedback provided by the red LED is more direct when receiving IR. The LED didn't use to light up until after a full iteration of the signal, plus a timeout. It now already lights up after a few pulses have been received that match the IRP definition of any one of the 8 decoders. The slight downside to this early indication of an IR signal is that it may turn out to be wrong in some circumstances. This does not normally turn out to be an issue.
For more information, see the espirp web site.
* Receiving IR signals still has some limitations. First of all, only IR signals can be received that have a carrier frequency close to the nominal frequency of the installed IR receiver component. Additionally, it is possible to construct an IRP definition that is too complicated to use for decoding an IR signal. This happens mainly when the number of bits or the duration of a signal is specified using a variable or expression. This is very rare in normal IR signals. The only example in the IRP definitions included in the published firmware is the Zenith protocol. That allows the function value to be transmitted as 5 to 8 bits. The number of bits is represented as the device code. It is still possible to receive such signals by configuring the device code on the decoder.
With firmware 3.0, the IR capabilities of the espirp are now completely driven by the installed IRP definitions. Transmitting IR signals was already based on IRP definitions. This is now also true for receiving IR signals. So the device is no longer limited to receiving only a fixed set of hard-coded IR signal families. This means that adding full support* for a new IR signal family is as simple as entering an IRP string on a built-in web page.
Receiving IR signals is now handled by decoders. Currently there are 8 decoders available. Each decoder can be configured to handle one IR protocol. It is expected that 8 decoders suffices for normal use. The reported signals can be narrowed down further by specifying a value for one or more variables of the IRP definition.
A change from firmware 2.x is that NEC1 and NEC2 signals are no longer reported as just NEC. Depending on which of the protocols has been assigned to one of the decoders, that protocol is reported. Since the first iteration of NEC1 and NEC2 signals are identical, a decoder configured for NEC1 will report a single iteration of a NEC2 signal. The reverse is also true. If it is important to distinguish the two protocols, a subsequent iteration must be checked (using receive full mode). A NEC1 decoder will only report subsequent iterations of a real NEC1 signal. The same is true for a NEC2 signal and a NEC2 decoder. Signals with so-called dittos (for example NEC1) are now reported (in receive full mode) with the full information, not simply with device 0, function 0.
When dealing with a unknown IR protocol, the espirp can be set to capture mode via the Interact web page. The pulse durations of received IR signals will then be reported. Clicking on a list of pulse durations will present a graphical representation of the signal. The signal is also compared against all installed IRP definitions. Any matches are listed.
Finally, some other improvements to the reception of IR signals have been made: Filtering of stray IR noise between repetitions of the signal has been added. This makes it less likely that a long button press will be reported as multiple presses. And the feedback provided by the red LED is more direct when receiving IR. The LED didn't use to light up until after a full iteration of the signal, plus a timeout. It now already lights up after a few pulses have been received that match the IRP definition of any one of the 8 decoders. The slight downside to this early indication of an IR signal is that it may turn out to be wrong in some circumstances. This does not normally turn out to be an issue.
For more information, see the espirp web site.
* Receiving IR signals still has some limitations. First of all, only IR signals can be received that have a carrier frequency close to the nominal frequency of the installed IR receiver component. Additionally, it is possible to construct an IRP definition that is too complicated to use for decoding an IR signal. This happens mainly when the number of bits or the duration of a signal is specified using a variable or expression. This is very rare in normal IR signals. The only example in the IRP definitions included in the published firmware is the Zenith protocol. That allows the function value to be transmitted as 5 to 8 bits. The number of bits is represented as the device code. It is still possible to receive such signals by configuring the device code on the decoder.
Schelte
Re: ESPIRP project.
I have a ESPIRP WiFi Infrarood zender/ontvanger from Nodo-Shop.
Receiving and transmitting signals from and to my TV set and remote are working fine from the web interface.
Receiving from the TV remote by MQTT is also working fine.
Transmitting to the TV by MQTT wil not work even after following instructions on https://espirp.tclcode.com/index.html
Please supply further instructions how to get it working.
See pictures enclosed for some information of the settings used.
With regards
Receiving and transmitting signals from and to my TV set and remote are working fine from the web interface.
Receiving from the TV remote by MQTT is also working fine.
Transmitting to the TV by MQTT wil not work even after following instructions on https://espirp.tclcode.com/index.html
Please supply further instructions how to get it working.
See pictures enclosed for some information of the settings used.
With regards
- Attachments
-
- 2.png (56.96 KiB) Viewed 58302 times
-
- 1.png (49.56 KiB) Viewed 58302 times
Re: ESPIRP project.
It definitely works. I'm using it on a daily basis.
You haven't disclosed what you tried. That makes it hard to pinpoint what you may be doing wrong.
You haven't disclosed what you tried. That makes it hard to pinpoint what you may be doing wrong.
Schelte
Re: ESPIRP project.
To conclude, firmware 3.0 brings a significant improvement in the IR capabilities of the espirp. It makes it much easier to add new IR protocols and decode more complex signals. Some limitations still remain, but they are mostly due to practical considerations rather than technical limitations of the device.
I hope that many users will find this update useful for their home automation projects or other IR-based applications.
I hope that many users will find this update useful for their home automation projects or other IR-based applications.
Re: ESPIRP project.
I have received a ESPIRP WiFi Infrarood receiver from the Nodo-Shop. After assembling it and flashing the firmware it works perfectly when selecting one of the predefined IR families 
Now my challenge: For my Denon AVR receiver (3808) I use the Denon-K family. This works fine for the most buttons but not all (eg volume up and down is not recognized also the navigation buttons do not work + some others). I have tried all families but not of them seem to work.
Raw capture of code that works
Times: 3418,1632,486,356,460,382,482,1198,482,360,482,1202,482,358,484,1194,486,356,482,360,482,1198,482,360,482,360,512,1168,482,1202,482,356,456,386,512,330,508,334,456,386,482,356,486,356,486,356,456,1224,512,330,486,1194,512,330,486,356,486,356,482,1198,486,1194,486,356,486,356,486,356,482,1200,512,330,482,360,482,360,482,360,482,356,486,356,486,1196,484,1198,482,360,456,382,482,1204,456,1220,488,1196,482,360,482
Raw capture of code that does not work
Times: 326,730,326,730,326,1788,328,1782,326,730,352,704,352,1762,322,1788,326,730,352,1758,326,730,326,1788,326,1784,326,730,328,730,326
Times: 330,730,328,730,328,1782,328,1782,328,730,326,1788,352,704,326,730,328,1782,328,730,356,1758,326,730,352,704,326,1782,352,1762,352
Times: 328,728,352,704,326,1788,326,1782,328,730,326,730,326,1782,326,1788,326,730,356,1754,326,730,326,1788,326,1784,326,730,352,704,326
I have also tried to set-up / use the code for Denon-K as mentioned in the JP1 site like below
{37k,432}<1,-1,1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,((D*16)^S^(F*16)^(F:8:4)):8,1,-173)+
This one doesn't seem to work at all. So the definition in the firmware for Denon-K is different (or I am doing something wrong).
Now my questions:
* Is there a reason why not all Denon Receiver buttons work with the Denon-K family. Is there another family I should use
* Is there a way that I can see how the build up is of the IRP files in the original BIN file? (maybe I do something wrong and this is why the above code of the JP1 side doesn't work at all).
Thanks for helping out.
Rob
Now my challenge: For my Denon AVR receiver (3808) I use the Denon-K family. This works fine for the most buttons but not all (eg volume up and down is not recognized also the navigation buttons do not work + some others). I have tried all families but not of them seem to work.
Raw capture of code that works
Times: 3418,1632,486,356,460,382,482,1198,482,360,482,1202,482,358,484,1194,486,356,482,360,482,1198,482,360,482,360,512,1168,482,1202,482,356,456,386,512,330,508,334,456,386,482,356,486,356,486,356,456,1224,512,330,486,1194,512,330,486,356,486,356,482,1198,486,1194,486,356,486,356,486,356,482,1200,512,330,482,360,482,360,482,360,482,356,486,356,486,1196,484,1198,482,360,456,382,482,1204,456,1220,488,1196,482,360,482
Raw capture of code that does not work
Times: 326,730,326,730,326,1788,328,1782,326,730,352,704,352,1762,322,1788,326,730,352,1758,326,730,326,1788,326,1784,326,730,328,730,326
Times: 330,730,328,730,328,1782,328,1782,328,730,326,1788,352,704,326,730,328,1782,328,730,356,1758,326,730,352,704,326,1782,352,1762,352
Times: 328,728,352,704,326,1788,326,1782,328,730,326,730,326,1782,326,1788,326,730,356,1754,326,730,326,1788,326,1784,326,730,352,704,326
I have also tried to set-up / use the code for Denon-K as mentioned in the JP1 site like below
{37k,432}<1,-1,1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,((D*16)^S^(F*16)^(F:8:4)):8,1,-173)+
This one doesn't seem to work at all. So the definition in the firmware for Denon-K is different (or I am doing something wrong).
Now my questions:
* Is there a reason why not all Denon Receiver buttons work with the Denon-K family. Is there another family I should use
* Is there a way that I can see how the build up is of the IRP files in the original BIN file? (maybe I do something wrong and this is why the above code of the JP1 side doesn't work at all).
Thanks for helping out.
Rob
Re: ESPIRP project.
Denon uses a mix of 2 completely different IR signal families. Within the espirp these are called Denon-K and Denon. For the volume and cursor keys your Denon receiver apparently uses the Denon signals.
As the JP1 site mentions: "A Denon signal has two halves, either one of which is enough to fully decode the information". These two parts cause a bit of a problem for decoding the signal. There is an equally big gap in the middle of the signal as there is between signals. So it's not possible to tell which is which. As a result, the firmware splits the two halves. But then the signal does not match the IRP definition, which defines both halves.
You can also see this when clicking on the captured raw signals. All the odd signals show a very similar signal waveform, as do all the even signals. But there is a substantial difference between the odd and even signals. Like this:
As a work-around, you can define the two halves as individual signal families on the "IR Signals" web page. Add the following two families:
Denon{1}: {38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165)+
Denon{2}: {38k,264}<1,-3|1,-7>(D:5,~F:8,3:2,1,-165)+
If you then add both families as decoders, you will see something like this on the Interact web page when a Denon IR signal is received (in basic mode):
Family: Denon{2}, Device: 12, Function: 163
Family: Denon{1}, Device: 12, Function: 163
Family: Denon{2}, Device: 12, Function: 163
Family: Denon{1}, Device: 12, Function: 163
You can see the IRP definitions of the existing families on the "IR Signals" page. Enter an IR family name, or select it from the drop down list. The current definition will then be shown.
This technique reveals that the Denon-K family is defined as:
{37k,432}<1,-1|1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,C:8,1,-173)+{C=(D*16)^S^(F*16)^(F:8:4)}
This would be equivalent to:
{37k,432}<1,-1|1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,((D*16)^S^(F*16)^(F:8:4)):8,1,-173)+
That is almost what the JP1 site says, except for a typo. The bitspec is supposed to specify what different groups of bits look like. There should normally be at least two IRstreams separated by a | to define a single bit being 0 or 1. The broken definition only has a single IRstream. You can't make different IR signals with that. The comma in the middle should have been a pipe symbol.
As the JP1 site mentions: "A Denon signal has two halves, either one of which is enough to fully decode the information". These two parts cause a bit of a problem for decoding the signal. There is an equally big gap in the middle of the signal as there is between signals. So it's not possible to tell which is which. As a result, the firmware splits the two halves. But then the signal does not match the IRP definition, which defines both halves.
You can also see this when clicking on the captured raw signals. All the odd signals show a very similar signal waveform, as do all the even signals. But there is a substantial difference between the odd and even signals. Like this:
- denon.png (5 KiB) Viewed 47518 times
As a work-around, you can define the two halves as individual signal families on the "IR Signals" web page. Add the following two families:
Denon{1}: {38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165)+
Denon{2}: {38k,264}<1,-3|1,-7>(D:5,~F:8,3:2,1,-165)+
If you then add both families as decoders, you will see something like this on the Interact web page when a Denon IR signal is received (in basic mode):
Family: Denon{2}, Device: 12, Function: 163
Family: Denon{1}, Device: 12, Function: 163
Family: Denon{2}, Device: 12, Function: 163
Family: Denon{1}, Device: 12, Function: 163
You can see the IRP definitions of the existing families on the "IR Signals" page. Enter an IR family name, or select it from the drop down list. The current definition will then be shown.
This technique reveals that the Denon-K family is defined as:
{37k,432}<1,-1|1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,C:8,1,-173)+{C=(D*16)^S^(F*16)^(F:8:4)}
This would be equivalent to:
{37k,432}<1,-1|1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,((D*16)^S^(F*16)^(F:8:4)):8,1,-173)+
That is almost what the JP1 site says, except for a typo. The bitspec is supposed to specify what different groups of bits look like. There should normally be at least two IRstreams separated by a | to define a single bit being 0 or 1. The broken definition only has a single IRstream. You can't make different IR signals with that. The comma in the middle should have been a pipe symbol.
Schelte
Re: ESPIRP project.
Hi Schelte,
Thx very much for your help.
After defining the Denon-1 and Denon-2 codes the application was able to decode the signals exactly as you where saying. For transmitting the signal I need to use Denon-1 & Denon-2 alternately otherwise it will not work. On the other hand the Denon IRP did work for transmitting the IR code to the device. So, now I can use Denon-1/2 for understanding which device/function every button has and Denon for transmitting when needed.
The definitions itself are however not visible when choosing a family in the IR signals page. See below image were I selected the Denon-K code.
I tried using different browers (google & edge on windows & safari on an iPad) but the definition itself is not shown (only a blank field). Doing this is also tricky because when you, by accident, hit enter it will be the same as save. The result is that you will delete the family as the defintion is blank...
I have re-uploaded the bin files but this didn't change anything & I also tried the OTA update but the firmware stayed the same / skipped. See below the status overview of my configuration.
Thanks for this great application....It is very simple to use and with MQTT I can easily integrate this in my Homeseer automation set-up.
Thx Rob
Thx very much for your help.
After defining the Denon-1 and Denon-2 codes the application was able to decode the signals exactly as you where saying. For transmitting the signal I need to use Denon-1 & Denon-2 alternately otherwise it will not work. On the other hand the Denon IRP did work for transmitting the IR code to the device. So, now I can use Denon-1/2 for understanding which device/function every button has and Denon for transmitting when needed.
The definitions itself are however not visible when choosing a family in the IR signals page. See below image were I selected the Denon-K code.
- IR signals.png (104.23 KiB) Viewed 47506 times
I tried using different browers (google & edge on windows & safari on an iPad) but the definition itself is not shown (only a blank field). Doing this is also tricky because when you, by accident, hit enter it will be the same as save. The result is that you will delete the family as the defintion is blank...
I have re-uploaded the bin files but this didn't change anything & I also tried the OTA update but the firmware stayed the same / skipped. See below the status overview of my configuration.
Thanks for this great application....It is very simple to use and with MQTT I can easily integrate this in my Homeseer automation set-up.
Thx Rob
- status.png (162.84 KiB) Viewed 47506 times
Re: ESPIRP project.
Most peculiar. The javascript code is checking the inputType property of the event. Chrome is supposed to support this since version 60, but somehow it is not present in version 126. I normally use Firefox, where it is all working fine.
You can however hit enter in the IR family field. That will show the definition. It will not invoke the Save action and delete the signal. The javascript is preventing that from happening. At least that part is also working correctly in Chrome.
I have made a small change to the javascript to work around the shortcoming of Chrome. I also found another thing that tripped up Chrome. Both of these changes are easily fixable by uploading the attached files to the espirp (unzip and upload the signals.js and signals.html files one by one via http://espirp1/upload.html).
And yes, always use the complete Denon signal to transmit Denon IR signals. The Denon{1} and Denon{2} signals were only intended to enable decoding the received signal. I will think about coming up with a way to make it possible to decode the signal based on the full signal, without the need to chop the signal in two.
You can however hit enter in the IR family field. That will show the definition. It will not invoke the Save action and delete the signal. The javascript is preventing that from happening. At least that part is also working correctly in Chrome.
I have made a small change to the javascript to work around the shortcoming of Chrome. I also found another thing that tripped up Chrome. Both of these changes are easily fixable by uploading the attached files to the espirp (unzip and upload the signals.js and signals.html files one by one via http://espirp1/upload.html).
And yes, always use the complete Denon signal to transmit Denon IR signals. The Denon{1} and Denon{2} signals were only intended to enable decoding the received signal. I will think about coming up with a way to make it possible to decode the signal based on the full signal, without the need to chop the signal in two.
- Attachments
-
- signals.zip
- (4.67 KiB) Downloaded 298 times
Schelte
Re: ESPIRP project.
Hi Schelte,
Uploading the two files did work perfectly. The definitions are now directly visible when selecting a family in the drop down menu button. Thanks for the quick investigation & solution. I can very much recommend the small IR transceiver (purchased via the Nodo Shop). It has a great range and as mentioned it is easy to integrate with MQTT/API in a home automation solution.
Your work for the community (I have also an OpenTherm gateway running already for +/- 10 years flawlessly) is very much appreciated.
Thx again,
Rob
PS: In the old situation without the fix hitting enter in the definition field did delete the selected family (when using chrome). At least it wasn't visible anymore in the dropdown menus. It maybe has to do with the exact browser version (my version = Versie 126.0.6478.127 (Officiële build) (64-bits)). Anyway with the fix applied this is now all solved.
Uploading the two files did work perfectly. The definitions are now directly visible when selecting a family in the drop down menu button. Thanks for the quick investigation & solution. I can very much recommend the small IR transceiver (purchased via the Nodo Shop). It has a great range and as mentioned it is easy to integrate with MQTT/API in a home automation solution.
Your work for the community (I have also an OpenTherm gateway running already for +/- 10 years flawlessly) is very much appreciated.
Thx again,
Rob
PS: In the old situation without the fix hitting enter in the definition field did delete the selected family (when using chrome). At least it wasn't visible anymore in the dropdown menus. It maybe has to do with the exact browser version (my version = Versie 126.0.6478.127 (Officiële build) (64-bits)). Anyway with the fix applied this is now all solved.