JP1 Remotes

I have grown very fond of JP1, RMIR and my remote of choice, the Xsight Touch / Nevo C3. That said, I think there has to be a better remote option. With all the programming and hardware knowledge that exists in these forums, wouldn't it make sense for a group here to take on the project of creating the ultimate programmable remote. I have to believe their are enough jp1 people who would be willing to fund it, myself for one. Actually, you are half-way there as the software to program the remote and the code database is already available. I dont know that the goals have to be that lofty either. For instance, I just want a more ergonomical and durable remote With the same capabilities as my Xsight.

Just a thought...

Let me chime in on this.

First of all, IR control is considered a legacy technology, so... It may be a good idea to throw in a (subset of) RF (315/433/868 MHz), bluetooth, WLAN (TCP and UDP sockets), etc, to make it attractive.

Consider for example my little project, with the firmware AGirs. It contains a sending engine, learning, and receiving. There is support for a simple LCD display and 433 MHz RF, and Ethernet (in the sense of the Arduino Ethernet (W5100) or Ethernet2 (W5500) library). Some improvements are easily suggested: Replace the aged Atmega328 board with a modern 32 bitter; Tenex3.x comes to my mind, but there are several alternatives. Touch display. Most importantly, a keyboard.

But there is an incredible difference between a experimental, possibly breadboard based design and a robust, commercial-quality "clicker" that can be used by a drunk user or an infant without breaking. Here lies "the rub".

A very interesting, alternative project, possibly more realistic, would be to develop a completely free (open source) firmware for a remote like an XSight or Harmony.

Another very interesting alternative is to develop a free remote control apps for Android, possibly also for iOS. A few years ago, many smartphones came with an "IR Blaster", but it seems to be considered "legacy" now. Instead, a device like my above mentioned Arduino Nano, the IrToy, or the USB IrDroid (this is essentially a stripped-down IrToy to a beefed-up price) can be used. To my knowledge, no free (open source) suitable app exists. ("irplus" comes resonably close, but is not open source.) Such an app can easily support bluetooth and TCP. Due to the hardware, it comes with a very good touch display , WLAN, bluetooth, etc.

Food for thoughts...

Barf wrote:Let me chime in on this.

First of all, IR control is considered a legacy technology, so... It may be a good idea to throw in a (subset of) RF (315/433/868 MHz), bluetooth, WLAN (TCP and UDP sockets), etc, to make it attractive.

Consider for example my little project, with the firmware AGirs. It contains a sending engine, learning, and receiving. There is support for a simple LCD display and 433 MHz RF, and Ethernet (in the sense of the Arduino Ethernet (W5100) or Ethernet2 (W5500) library). Some improvements are easily suggested: Replace the aged Atmega328 board with a modern 32 bitter; Tenex3.x comes to my mind, but there are several alternatives. Touch display. Most importantly, a keyboard.

But there is an incredible difference between a experimental, possibly breadboard based design and a robust, commercial-quality "clicker" that can be used by a drunk user or an infant without breaking. Here lies "the rub".

A very interesting, alternative project, possibly more realistic, would be to develop a completely free (open source) firmware for a remote like an XSight or Harmony.

Another very interesting alternative is to develop a free remote control apps for Android, possibly also for iOS. A few years ago, many smartphones came with an "IR Blaster", but it seems to be considered "legacy" now. Instead, a device like my above mentioned Arduino Nano, the IrToy, or the USB IrDroid (this is essentially a stripped-down IrToy to a beefed-up price) can be used. To my knowledge, no free (open source) suitable app exists. ("irplus" comes resonably close, but is not open source.) Such an app can easily support bluetooth and TCP. Due to the hardware, it comes with a very good touch display , WLAN, bluetooth, etc.

Food for thoughts...

This is exactly what I am getting at, you are obviously a person with an engineering background and there many others here that have complimentary skillsets who are passionate about the total control JP1/RMIR affords us over our A/V components. If you take the concept further, we could find ourselves into the world of home automation as well. I just think there so much creativity here that there is a way to start by creating the perfect HT remote for the computer literate. Unfortunately, i do not think the Xsight or any of the other JP1 capable remotes offer a great hardware platform. I actually think the Harmony One and the Elite offer far better ergonomics and, while I love my Xsights, they are a disaster in terms of build quality. I own 4 of them just because i know each of them will have a very limited useful life.

On another note, I recognize that there is a lot of competition in the universal remote world, but none of those companiex cater specifically to an open source community and JP1 is so mature that I have to believe, niche as it may be, there is an opportunity here. Isn't this basically how Oppo got started? And they are now considered the standard bearer in the world of optical disc players, including Blu-ray and UHD.

nofhjy wrote:I have grown very fond of JP1, RMIR and my remote of choice, the Xsight Touch / Nevo C3. That said, I think there has to be a better bathmate remote option.

I think you're right about Oppo, nohjy. And many more companies had a similar start too. This looks like a great product and I'd certainly pitch in through a Kickstarter campaign.

WaldoRe wrote:I think you're right about Oppo, nohjy. And many more companies had a similar start too. This looks like a great product and I'd certainly pitch in through a Kickstarter campaign.

I have been thinking about the 'long term' as well.

Some 'interesting' products I have run across that have pieces of a future solution:

Wireless USB remote with limited IR capability:
https://www.amazon.com/ProChosen-Wirele ... te+with+ir

IP/IR/Cloud integration:
http://www.video-storm.com/proddetail.asp?prod=IRUSB

Custom CEC:
https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter

Certainly between IP control, CEC and Bluetooth, IR is going to go away, but there is not a unified solution...

I think the "ultimate" remote wouldn't need to be programmable at all. It would be a relatively dumb remote with a good key layout which simply sent keycodes via RF to a flexible base station. RF (Bluetooth low energy), so it doesn't need to be line of site. Two way with some status lights for the upscale version.

That base station would then handle all the programmability and interfacing - IR emitters, RF transmitters, direct wire, etc. as needed to interface to different components. Even WiFi and Ethernet to do network control and provide a web GUI for programming. Base stations could talk to each other for multiroom control.

mike.s wrote:I think the "ultimate" remote wouldn't need to be programmable at all. It would be a relatively dumb remote with a good key layout which simply sent keycodes via RF to a flexible base station. RF (Bluetooth low energy), so it doesn't need to be line of site. Two way with some status lights for the upscale version.

That base station would then handle all the programmability and interfacing - IR emitters, RF transmitters, direct wire, etc. as needed to interface to different components. Even WiFi and Ethernet to do network control and provide a web GUI for programming. Base stations could talk to each other for multiroom control.

Agree. I think the base station should also include HDMI-CEC. This part is actually not all that hard - a RaspPi can already do all that with the right collection of SW + Broadlink. I do have a 3d printer to make a prototype remote

So - been thinking about this more, and will be starting on the project for myself this weekend. Whether this changes into something to share I guess depends on interest.

My goal will be to duplicate the Harmony Hub functionality using a Raspberry Pi (may actually switch to using something NXP based later )

First goals:
- RF receive/learn
- IR receive
- Send IP controls (HTTP to start - sending to IFTTT)

Second level:
- RF transmit
- IR transmit
- HID receive via dongle
- HDMI-CEC transmit

Third level:
- Send Bluetooth HID
- Receive Bluetooth HID
- HDMI-CEC receive

Fourth level:
- Custom Bluetooth
- Custom IP Home Automation (SmartThings)
- Alexa

Fifth level:
- Custom remote

Thoughts?

I don't need much of this past level 2 for myself, so may never get there

mike.s wrote:I think the "ultimate" remote wouldn't need to be programmable at all. It would be a relatively dumb remote with a good key layout which simply sent keycodes via RF to a flexible base station. RF (Bluetooth low energy), so it doesn't need to be line of site. Two way with some status lights for the upscale version.

It can be even dumber, for example using "legacy" IR. Just a (non-configurable) clicker that sends commands to a "gateway", that relays them to a smart home automation system -- the configuration sits in the gateway. That way the IR remote complements a home automation system. Pressing a button on a clicker can faster and more reliable than voice control, in particular in noisy environments.

I am actually using this: As receiver an Arduino Nano with a TSOP-***+ (like this with this firmware), and the Dispatcher software running on a Raspie as gateway. The latter is configured with an XML file, and can relay to other programs and hosts (TCP/UDP/HTTP), wake up with WOL-protocol, etc.

xnappo wrote:So - been thinking about this more, and will be starting on the project for myself this weekend. Whether this changes into something to share I guess depends on interest.

My goal will be to duplicate the Harmony Hub functionality using a Raspberry Pi (may actually switch to using something NXP based later )

First goals:
- RF receive/learn
- IR receive
- Send IP controls (HTTP to start - sending to IFTTT)

Second level:
- RF transmit
- IR transmit
- HID receive via dongle
- HDMI-CEC transmit
...

Nice. Some comments:

* IMHO, we should try to understand the RF protocols (315, 415, 433, 868 MHz) as we understand the IR protocols. Basically, an RF protocol is "the same" as an IR protocol, with the modulated IR light replace by a non-modulated RF signal. See this thread. There I have a complete analysis of the Arctech protocol "with code wheel", as an IRP form. I have also IRP-ifyed the so-called RS-200 protocol ("Conrad"). That way, "learning" is secondary.

* I consider sending and receiving from an Arduino a better idea than using a Raspie, simply because the former just does one thing only, while the Raspie runs a multi-tasking OS (in general Linux). Be sure to check out my Arduino firmware. (It supports sending 433 MHz directly with a module.)

* I have had bad experiences (but not given up ) with receiving RF using the cheapie modules. The Broadlink can be a good alternative, at least as long as we are analyzing protocols.

* There are some interesting contributions on CEC in the Eventghost forum.

More later...

FWIW, I have uploaded some notes I made a few years age, trying to classify RF systems here.

Thanks - the first thing I am doing is actually the protocol the XSight uses with the RF base station. Will be interesting to see if it is the 'One for all' protocol.

So.. Home Assistant does almost EVERYTHING on my wish list. It is a deep rabbit hole - see y'all in a few weeks

https://home-assistant.io/

Barf wrote:[...]Basically, an RF protocol is "the same" as an IR protocol, with the modulated IR light replace by a non-modulated RF signal.[...]

Well, that's a big oversimplification :). There're much more things to consider when dealing with RF. A specific band (433, 868, 915 MHz etc) can be further split into channels of different widths, the signals can use different modulation techniques like FSK, ASK or PSK. Also they can differ in data rates.

I've been researching the subject for the purpose of controlling the lighting in my home, which consist of battery powered RF wall switches and RF controlled mains relays, produced by a Polish company Zamel. It uses 868 MHz modules compatible with RFM12B with FSK modulation. I now have my own working gateway built using Rasbperry Pi 3 + RFM12B + ATMega328 as a co-processor (ATMega connects to RFM12B using SPI and to RPi3 using UART).

Regarding learning the RF signals, it's something much harder with RF, because there's much more noise. Without understanding the frame format there's no way to know where to stop receiving. I've had this problem when I've been analysing the Zamel protocol. I knew what where the lead-in bytes that activate the receiver buffer in RFM12B (they are documented in the chip's datasheet) but I've been getting a lot of garbage. Basically you need to know when to inform the receiver module to stop filling the receive buffer. In case of Zamel protocol the frame has a constant length, but other protocols often contain the length field making the frame length variable.