IR Remote functionality

[st...@marshallarts.com.au]

Hi All.  Has anyone done any work on making a device which can act as an IR remote?  I know there is the MppIrRC6 device in Mike's ecosystem, but that looks to me like it's the other way around - it allows an IR remote to control Mpp devices.  I want an Mpp device to BE an IR remote.  Background - I've just had a Fujitsu reverse-cycle aircon installed.  I could have bought it with WiFi functionality, but the installer advised against it, he seemed to think it wasn't a very good implementation. Even if it worked OK, it would almost certainly have required cloud connection, which I don't like much.

So, what I'd like is simply to be able to turn it on/off remotely, and maybe change other modes too - heat/cool, fan speed etc.  Naturally I thought of an Mpp device.  I've seen the Sensibo devices which basically do this, but they definitely work via the cloud, and only via the cloud as far as I can see.  I don't mind forwarding a port for something like this, but I don't like a permanent connection from my network to the cloud.

I have a spare Wemos D1 Mini lying around, so have ordered an IR transceiver shield for it with the intention of doing some experimentation.  I guess I should start by examining the code for the MppIrRC6 device, and even install and run it on the Wemos, I think it should allow me to see what codes the handheld remote generates for each button.  I've done a few code mods to Mpp devices before, but fairly minor.  Any advice much appreciated.

[DougC]

I mucked around with this 4 or more years ago. There was some discussion here iirc. I took some sample IRrepeater code and merged in the basic Mpp bits to get a standalone device that could transmit / receive / repeat IR signals and also communicate these decoded messages into Automation Manager or conversely take commands from Automation Manager to generate IR. My memory is a bit vague on this (bit vague about everything these days tbh). I never completed the project but have dug out the original breadboard which still, remarkably, works.  I've not done any customisations for years and I realise that none of what I did back then would recompile with current versions. I'll see if I can wake the old brain up...

[trogli...@gmail.com]

Right, what I did with IrRC6 was a proof of concept – it uses a library to receive the signal and make it available for use in AM as a value event (the command).  The idea is that yes, you can use those IR devices to receive and send IR messages.

I’d already played around with it on the PC to automate turning on a TV, sound system, etc and it works well – tho more modern devices don’t need it anymore…  It’s certainly possible to send IR from an MPP device.  The tricky part is the protocol, there’s a few and it’s hard to know which one applies, and then which command you want to send over IR.  I’d have a look at the available Arduino libraries to see what they have, and I’d probably use IRRemote in a PC to figure out the protocol and the commands.

--
You received this message because you are subscribed to the Google Groups "MppDevices" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mppdevices+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mppdevices/3667a006-abf1-48b0-8029-fcb474d09767n%40googlegroups.com.

[st...@marshallarts.com.au]

Back on topic, with project number 2...

I now seem to have everything the Arduino IDE needs, it isn't complaining about any missing files.  But what I AM getting is a couple of compilation errors, one in MppServer.cpp and one in one of the ESP8266 libraries from Arduino.  Doesn't seem right to me.  I have the latest version of the IDE, and I'm running on Windows.  I might try putting the IDE on my Linux box, in case there is some subtle difference between the compilers on different platforms.  Any other suggestions welcome.  The errors are shown below.

[Mike P 4 MPP]

It looks like the problem in MppServer.cpp is an artifact from the problem in WString.h - that's the definition of the operator "+=" to append a char* to a String.  I'm guessing a version mismatch.  It looks like you might be using the ESP8266 base 3.1.2, is that right?  MPP code needs to be built on 2.7.4: https://sites.google.com/site/mppsuite/esp2866/flashing-firmware/building.

[st...@marshallarts.com.au]

Ah rats.  Yes that was it, sorry.  I thought I'd done that, but I've been faffing around with these libraries so much, uninstalling and instaling, that the latest version snuck back in there.  Yes it now compiles.  Thanks.

[st...@marshallarts.com.au]

OK, it compiles, it uploads to the Wemos D1 mini, and it comes up and runs.  It's definitely my build because I gave it a distinctive version number.

If I point the aircon remote at it and press a button, it definitely detects something.  The two lines below both result from pressing the Power button.  The first is a button-press that would turn the aircon ON, the second would turn it OFF.

• 2024.07.21 22:19:07.693 Decoded protocol 33 bits 0x80 value 0x3109fe1010006314 address 0x30479 command 0x2f200000 
• 2024.07.21 22:19:13.755 Decoded protocol 33 bits 0x38 value 0xfd021010006314 address 0x0 command 0x0  
  

Protocol 33 is definitely the FUJITSU_AC one.  The values seem to be consistent over several button-presses, which has to be good I guess.  Making sense of all this is the next challenge.  The 0x80 and 0x38 seem to be the decoded bit count.  It's not clear to me (yet) what the "command" and "address" values are about, I was expecting just one single stream of bytes for each action, and under the hood it must be like that.  But I guess the library this uses knows something about what parts of the data stream do what.  Next thing I'll do is put my Wemos gizmo in front of the Sensibo Sky and capture what it sends when it is told to send a command to the aircon.  I'll certainly be expecting (hoping?) it will look the same.  If it isn't then there will be even more head-scratching.  I will be proceeding very cautiously - I have seen something online warning that sending invalid data to the aircon can lock up the controller, requiring a factory reset, gulp.  Anyway, seeing consistent decoded values is a good line to cross.  All good fun!

[Mike P 4 MPP]

Cool, that's good progress :).

[st...@marshallarts.com.au]

Well, I pointed the Sensibo Sky at the Wemos IR receiver and activated it, but all I am getting is "Protocol -1 not recognised" messages.  I'm somewhat taken aback by that.  What to make of it?  I guess it means there is a fair bit of latitude in the signal characteristics that will be accepted by the aircon receiver.  I tried changing the MinPulseWidth
 from 300 to 250 but it made no difference.  I also tried adjusting the pulseWidth property both higher and lower, but it still cannot decode the signal from the Sensibo.  The handheld remote continued to work ok with all these adjustments.  So I'm a bit puzzled at the moment.

[st...@marshallarts.com.au]

I note from trawling through the code in the Github project this uses, that my aircon remote model number is not mentioned there.  May not be a good sign.

[st...@marshallarts.com.au]

...but the fact remains that both the handheld remote and the Sensibo can successfully command the aircon to do things.  So their signals must be similar enough at some level.  Unless of course the aircon IR receiver can accept more than one protocol.  That seems fairly unlikely to me, but what would I know?  This all just got even more mysterious.

[sergey]

Good progress , Steve! You approaching to my theme  - looking forward for final solution )) - I'm trying to sort out my Mitsubishi Heavy 2 wired protocol , between wall mounted remote and ducted AC. 

What I've learnt till now - is that one system can use several protocols for data exchange between the blocks (remote, internal, external and etc.) - The same with remote - It might be different Pulse Code Modulation within different function.., but it also can be mine hallucinations )

Btw, Sensibo has claimed that they support my Mitsubishi PAR-JH050KA , but I'm afraid it's a lie because there is no any IR port on that remote control and what they really support - is a question.

So the best way, IMHO,  would be in understanding the protocol of your AC with IR remote..