JP1 Remotes

RMDU here: https://www.hifi-remote.com/forums/dload ... e_id=26725

testing POWER OFF code (#21)

Installed latest version (RMIR.v2.14.18)

with original rmProtocols.xml
*Doesn't work*

0000 006D 0072 0000 0078 003C 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 000F 000F 0776



with newer rmProtocols.xml from:
https://www.hifi-remote.com/forums/dload ... e_id=26723
*Doesn't work*

0000 006D 0072 0000 0078 003C 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 000F 000F 0776

Pronto Hex provided by @Robman (Posted: Sat May 13, 2023 10:59 am)
***works***

0000 006D 0072 0000 0078 003C 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 002D 000F 002D 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 0776

at first glance 1 and 2 seem to be identical.
other than replacing rmProtocols.xml, anything else I need to do to ensure the changes are applied when exporting?

Open to further testing, let me know what you think.
Thx,

ylaviolette, when you're posting Pronto hex strings for comparison purposes, they have to be for the same signal otherwise it's meaningless. Remember, it's just the checksum that we're trying to fix here, and that is calculated by doing a SUM over all the bits in the signal, so if the bits are different, the checksum will be different, so pasting in my working hex string would only be beneficial if you were testing with the exact same settings (ie, mode sw=off, mode=cool, temp=20c, swing=on, fan=high, time sw=off, time=0).

I loaded your RMDU file into RM (using the updated rmProtocols.xml) and then I generated a Girr and got this (different) string for POWER OFF.

0000 006D 0072 0000 0078 003C 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 002D 000F 002D 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 000F 002D 000F 002D 000F 002D 000F 002D 000F 000F 000F 0776

Comparing the binary of your signal to mine, I can see that the checksum is different, so the only conclusion that I can come to is that you haven't really saved rmProtocols.xml into your RM folder.

11000100 11010011 01100100 10000000 00000000 00000100 11000000 00010000 00011100 00000000 00000000 00000000 00000000 00011010 - yours
11000100 11010011 01100100 10000000 00000000 00000100 11000000 00010000 00011100 00000000 00000000 00000000 00000000 00011110 - mine

Thx @Robman, the first two are for the same signal. Third one was just to show yours (though it's another signal) is working for some reason. I agree it seems to be an issue with the new file not doing its job.

Just to Confirm, rmProtocols.xml has to be replaced in RMIR root folder right?

@barf also mentioned something about the version :

"If you change an rmProtocols.xml (or IrpProtocols.xml), please change the version, found as attribute "version" in the top element. Just put in anything that has not been used already; bump the number or append something for example."

Should I consider this?

Will do further testing later today and I'll send a screen recording to confirm I'm not doing something wrong if needed...

Fingers crossed. Thx again

ylaviolette wrote:at first glance 1 and 2 seem to be identical.

(They are identical). Again, "this cannot happen". Did you

... restart RM(IR). (RMIR-> Help -> About should now say IrpProtocols version 2022-05-07+rm2023-05-13.)

If you still cannot figure out what goes wrong, upload rmaster.err.

And please upload your rmir/rmdu file; Rob seem to know it, but I do not.

@barf also mentioned something about the version :

"If you change an rmProtocols.xml (or IrpProtocols.xml), please change the version, found as attribute "version" in the top element. Just put in anything that has not been used already; bump the number or append something for example."

Should I consider this?

The theory states that whenever someone publishes a new version of an "old" file, the version is to be changed. This helps both humans and programs to know what database is used//has been used. So it does not help here.

other than replacing rmProtocols.xml, anything else I need to do to ensure the changes are applied when exporting?

Restarting (the file is read only on startup). Check Help-> About..

Ok. duh. the error was on my side....

To make things more legible I got a habit of converting the Girr file to Pronto Hex via IRScrutinizer (I also have a home automation app using this format to bulk import signals) but thought IRScrutinizer was simply importing HEX data already within the Girr file... but it seems it re-processes the data from the protocol/parameters. So I guess until IRScrutinizer is updated with the new converter I'll have to extract the Pronto hex directly from the Girr file, which works....

Let me know if this makes sense.

Any way to make this update available to IRScrutinizer or other way to generate the same type of Pronto Hex text file ?

thanks for your patience on this one, much appreciated.

ylaviolette wrote: but it seems it re-processes the data from the protocol/parameters.

The command element has an attribute "master", which has the possible values "parameters", "ccf", and "raw", determining which one is considered the master. If you change to "ccf", the Pronto Hex will be the master.

Any way to make this update available to IRScrutinizer or other way to generate the same type of Pronto Hex text file

You can configure IrScrutinizer to use another IrpProtocols.xml file (Options -> IRP protocols database -> Select), but "patching" in the sense of rmProtocols.xml is presently not supported. (I should fix this, https://github.com/bengtmartensson/IrSc ... issues/294). Otherwise, as soon as you, Rob (and Graham?) declares the new checksum formula as correct and tested, I will check it in. Minutes later, a snapshot version will be available. An official release will be done later this year. (But you are probably fine with the snapshot version.)

Thanks for the feedback,
Here I can confirm as tested & working.

I guess I can wait for the snapshot version once Rob/Graham confirms, but out of curiosity, where can I find the "command" element?

Thanks !

I can confirm that the checksum works for this set of IR signals, but I haven't taken the time yet to understand why 85 is the right number. I'm pretty confident that it's because of how the temp setting is handled. So I would be ok with you checking it in and using it.

I have checked in the version with "85". (To IrpTransmogrifier, not to RMIR.) Corresponding snapshot if IrScrutinizer is found here. Note that these changes do not propagate automatically to RMIR.

@rob: 85 is the sum of the constant stuff. First we have the bytes of M (in the IRP), which amounts to 0x000126cb23, then there is a constant 2:4. Since the bit order is LSB, and it starts 4 bits into its byte, so it is a bit more complicated. With IrpTransmogrifier from the command line, it can be computed as

ylaviolette wrote:... out of curiosity, where can I find the "command" element?

In the xml code in the girr file; open with a text editor.

Sorry for the delay, for some reason I didn't get notified on new posts...
@barf The snap shot version works as expected, Thanks for the update, much appreciated.