IResp8266 - solution looking for a problem

[MikeP 4 MPP]

Played around with a few different things during the holiday lockdown.  One of them was using an IR receiver with the IRRemoteEsp8266 library (the receivers are < $1 each even from amazon).  Testing with an old HP media remote (NEC6 protocol) got me to where I've got a device that can report each button button press to AM.  So I've got a 40+ button handheld control now with no idea what to use it for...

If anyone else wants to get going with IR let me know and I'll send my code - though to be honest it pretty much just worked, very little innovation required...

[DougC]

Some long while ago I bought some IR emitters and receivers. Can't remember the exact chips offhand, nor where they are in fact. Had a dabble and then parked it after limited success if I recall. I think I was as much interested in the reverse function - being able to generate the IR signal - so that I could operate IR controlled things from AM. A smart IR blaster I suppose.

So yes, I would be interested in what you have done. Not that I need to start any more projects...

[MikeP 4 MPP]

My receivers are little 3-pin LED looking things wrapped in a metallic case that I believe are filtered for 36K or 38K reception.  My transmitters are clear LEDs that don't light (at a wavelength I can see).  I've got some black LED things that are basic receivers and they pick up those LEDs when I turn them on.   I'll publish my new source so you can see - it's MppIrRC6.ino/bin.  I haven't had success yet transmitting to the 3-pin receivers using the ESP8266 library yet.  Still playing...  if I get it going I'll update the source.  You'll want to add the IRremoteESP8266 library to your build environment.

I've only used it with NEC6/RC6 but I suspect it'll easily work with others too - at the very least you can see how to do a custom version.

The EPS8266 would probably make a handy little IR Remote box for receiving then sending signals to multiple targets - I did play with stuff like that for a while but settled on a harmony remote in the end since it had a higher acceptance factor...

The origin of this project was to see if I could figure out a way for my old roomba to locate itself, though so far I haven't had any success.  I'm thinking about setting up a lattice of IR signals to see if that'll give it a way to orient itself like the virtual walls they have.  I really hate hearing it bump around aimlessly when it's cleaning, and it keeps sucking up my ESP8266 parts and wires...

[DougC]

Sounds like I bought a similar set of components - a set of clear / black transmitter / receivers   and   some TSOP1738 receivers. Interestingly, one of the TSOP1738 is 'missing' from the packet so I probably have a breadboard somewhere with it still set up. Can't yet find any of my notes or test code sadly.

I also have problems at the user acceptance phase of some of my projects. Curiously, it is my chief acceptance tester who is usually guilty of vacuuming up my components.

[DougC]

Hey Mike. Did you publish your source code in the end? I looked in the usual places, I think,  but did not find it. As to my own previous efforts I realise they were back in the Lua days so long gone and forgotten now.

[MikeP 4 MPP]

Oops, sorry, hadn't gotten around to it - posted now.  Look in MppLibrary.zip for the source file MppIrRC6.ino for my latest.  No binary for it since it's pretty specialized for my use, but the source should show how the library is used.

[DougC]

Wow. Scratching below the surface this looks hugely complex. Hopefully will never need to actually understand it.

I set up a test with a TSOP1738 sensor and a Lolin mini on a breadboard.  I compiled MppirRC6 - just modded to accept other protocol types.

First thing I noticed was fairly regular reports of   "Protocol -1 not supported " even with my sensor completely covered up. So I guess that's some noise in the system. Did you see anything like that Mike?

So then I tried out all the IR remote controllers I could lay my hands on. One thing I noticed was if I held the remote too near the sensor it would often fail to decode properly. Not a problem in a real usage case of course, but confused me a bit in my testing.

A couple of remotes that use RC5 protocol seemed to be decoded pretty well. The numeric buttons mapped out to the correct numbers and the other buttons all seemed to give unique codes.

I have a Panasonic remote that was less straightforward. I think all the buttons were giving unique codes but unfortunately the numeric keys were mapped to  such as 16779271 for the "1" key. Not a show stopper.

Another remote that appears to use NEC protocol was curious. The numerics mapped  as 1 to 3, 2 to 4, 3 to 5 etc. Other buttons mostly worked but I was getting quite a lot of mis-reads.  

So on the whole a promising start.  

[MikeP 4 MPP]

Nope, no noise, mine seems relatively quiet.  I've only tried my HP remote and my roomba "virtual wall" so far.  The wall LED was seen by the sensor but not interpreted - I think it's on a different frequency so I assumed noise/interference.  It'd scramble the HP's signal, but the HP on it's own seemed stable.  There's no repeating signal function from the HP so that might be why it's relatively quiet.

[DougC]

I think my noise issue was just the usual (cheap) breadboard stuff. Though adding a few capacitors around the place may have helped too.

I now have an Mpp enabled module running that can receive and send (ie retransmit) IR for at least a few different IR remotes. I've also got it able to communicate by http/rest between different instances of itself so that if one receives, another can transmit. Also of course it can communicate in/out similarly with an AM server. However, beyond "Alexa, turn on the TV", not much practical use at the moment.

[DougC]

Mike. in the course of my messing around with this I found a use for what amounts to an OnEvent/OffEvent device in AM. Basically a virtual device that has an indeterminate state but can be flipped momentarily to ON or to OFF. My DIY attempt at this was to create a group with two flag devices in. Plus rules to flip one of the flag devices to be in the opposite state to the group. My makeshift solution does the job for me, but if you see any value in the idea then I'm sure there is a more elegant way ....

[MikeP 4 MPP]

Nice :).  MppSleeper does something like this - when it wakes it reports the monitored GPIO state as on or off, then returns to standby.  You can also create a custom event device which will remain off until turned on by an SetDevice action, then turn itself off 1/2s later.

I was using the "ValueIs" trigger to fire rules when that button was pressed on the HP remote but I don't really need a remote, voice works well enough :).

Your IR blaster idea is interesting - adding voice control to IR only devices - I might be able to find a use for that.