Hey @AntonJansen ,
I finished the code that merges the storage functions for IR and RF. I tried to push it to your repo but received a 403. Did you authorize me to make changes to the repo?
Thanks!
Yes, but it seems you did not accept my invite yet in github. It says the invite is still pending …
Weird, i thought i did…let me check…
I got it to work!
I had to change my map file in:
AIRCON_ON=2600bc016d390d0f0c2b0d0f0d100d0f0d0f0d0f0d0e0d0f0d0f0d0f0e0f0d0f0d2b0c0f0d0f0d0f0d0f0d0f0d100d0f0c2b0d2b0d2b0d0f0d0e0d2b0d0f0d0f0d0f0e0f0d0f0c0f0d0f0d0f0d0f0d0f0e0f0d0f0c0f0d0f0d0f0d0f0d0f0e0f0d0f0d0e0d0f0d0f0d0f0d0f0d100d0f0d0e0d0f0d0f0d0f0d2b0d2b0c0f0d0f0e0f0d0f0d0f0d0001406e380d0f0d2b0d0f0d100d0f0d0e0d0f0d0f0d0f0d0f0d0f0d100d0e0d2b0d0f0d0f0d0f0d0f0d0f0c100d0f0d2b0d2b0d2a0d0f0d0f0d2b0d0f0d0f0d0e0d100d0f0d0f0d0f0d0f0d0f0d0f0c100d0f0d0f0d2b0d0f0d0f0d2a0d0f0d0f0d2b0d100d0e0d2b0d0f0d0f0d2b0d2a0d0f0d0f0d0f0d100d0f0d0f0d0e0d0f0d0f0d2b0d2b0d2a0d2b0d2c0d0f0d2a0d0f0d2b0d2b0d0f0d2a0d2b0d0f0d0f0d0f0d0f0d0f0d0f0d0f0d0f0d0f0d0f0d0f0c100d0f0d2b0d2b0d2a0d0f0d0f0d0f0d0f0d100c100d0e0d0f0d0f0d2b0d2b0d2a0d0f0d0f0d100d0f0d0f0d0f0c0f0d0f0d0f0d100c100d0f0d0f0d0e0d0f0d0f0d2b0d100c100d0f0c0f0d0f0d0f0d2b0d0f0d100b100d0f0d0f0d0f0d0f0d100c100d0e0d0f0d0f0d0f0d0f0d0f0d100d0e0d0f0d2b0d2b0d0f0d2a0d0f0d0f0d000d05
Thanks
1 Like
Good to see you found the solution. What put you on the wrong path in the first place?
On Github it’s written that the change of the storage mechanism, changed also the format of the files and codes that are now stored in json. There is also the example of it.
I changed also the item file in:
Switch Air_cond_on "Aircon ON 25°C" { channel="broadlink:rm4mini:2747c1ce9c:command"
as the channel on the thing
Ah that explains it, we did not update the Alpha jar yet, but the documentation has been updated.
Yes, i am currently ironing out some bugs with the storage implementation, will commit today.
I just pushed an updated, please pull. There were some bugs with the RF commands that I fixed.
I also removed the mapping file part, as we can now make this static instead.
Sadly, I broke the tests with this. Please have a look 
I will continue tomorrow evening.
Cool, will take a look.
Thanks!
Updated the Alpha jar to include latest changes from me & ricardo.
Funny, i am looking at your commit story, and can see that you remove the ability to set the file names…i was just working on the same…anyway, i will look at your commit, fix the tests and adding a couple more bugs i found. I would recommend people not to download a new version until tomorrow, so they get something more ironed out.
Thanks!
Hello @AntonJansen ,
The last push i did contains the following:
-Fixed a couple of issues in tests (Some from your changes, some previous)
-Merged the code to for storage, so it is the same for RF and IR
-Fixed a couple of Bugs that were loading IR data into the RF Channels
-Added some more information about the way codes are stored and behave in the docs
-Fixed some styling issues, and some warnings
-While testing the binding with multiple devices, while the devices share the same storage, they are not aware of when another device learns/modifies/deletes a code. So the interface does not get updated.
My last commit attempts to resolve that by implementing the EventSubscriber interface for the BroadlinkMappingService Class. The idea is that when a device reloads its commands, all the other MappingService instances get a message about it, and they can reload too. Currently, it does not work, it throws the following errors in the logs:
05:27:38.667 [ERROR] [link.internal.BroadlinkMappingService] - bundle org.openhab.binding.broadlink:4.2.0.202404060811 (382)[org.openhab.binding.broadlink.internal.BroadlinkMappingService(663)] : Constructor with 0 arguments not found. Component will fail.
bundle org.openhab.core:4.1.1 (157)[org.openhab.core.internal.events.OSGiEventManager(28)] : Could not get service from ref {org.openhab.binding.broadlink.internal.BroadlinkMappingService, org.openhab.core.events.EventSubscriber}={service.id=970, service.bundleid=382, service.scope=bundle, osgi.ds.satisfying.condition.target=(osgi.condition.id=true), service.pid=org.openhab.binding.broadlink.internal.BroadlinkMappingService, component.name=org.openhab.binding.broadlink.internal.BroadlinkMappingService, component.id=663}
I will work on getting this ready, as it would be a great addition, as opposed to having to restart the devices every time you learn new codes.
Besides that, the things i would like to implement are mostly cosmetic:
-It would be great if after any successful modification of the storage, the parameter that holds the command label gets erased, as to make sure no unwanted overwrites happen. Not even sure if that can be done though.
-A bit of a nitpick. i do not like the “Check and save” name used to add a code…would it be better to just say “Save new code”?
-I own 1 RM3, and 2 different types of RM4. I noticed that for the RM3 and one of the RM4, the process to add a thing is different ( for one, the interface only asks for a thing name, for the other one, there is a couple of options present to add as thing, etc etc). I will try and see if i can make the behavior the same for all of them.
-All commands except “Learn” show you through the interface if the command has been successful or not. It would be good to implement that for “Learn” too
-I notice the handler functions used to learn codes are quite different between RF and IR. They even have different names. i would your input to understand if we should consolidate names and if there is any chance they can be consolidated.
The one that might be a bit more material is the last one.
Thanks!
Correct. Question, I never tried, but can the same command be played at another device without issues? In other words, can an IR command of a RM3 mini be send out on a RM4 pro without any issues? Or should we make the commands specific to a device?
From an user perspective, I think sharing the commands is preferable. As this would reduce the hassle of learning commands for multiple devices. What are your thoughts?
Nice idea, I will dig into it later tonight 
Agree, I started doing this for the RF piece. Will try to port it to IR as well, so the web UI gives a consistent user experience. On that note, is there a reason why you made the difference between adding and replacing a command? I think it is better from a user perspective to collapse them into one.
The flow for IR and RF are completely different. We could try to align a bit more the naming of them both.
Yes, it can. That is why the original binding allowed to share this file.
In my perspective, there is a case for both sharing a common file, and locking each thing to a file.
For the first one, the fact that you can learn something in one device and having it instantly available in all the others, without the need of copying or editing files is very valuable. For the second one, The software side becomes much easier (In fact, we are the only ones trying to share a storage object between several things. There is no other examples in all of OpenHAB bindings doing that. But it is also good for when you do not want a humongous list of commands attached to every single device. I would like to have both, but the most complicated and most valuable reward-wise is the first one, so that is the one i decided to tackle first.
Yeah, this needs work. It broke the command reloading (I only pick up on this a couple of mins ago) and the code committed shows i reach the point where I have no idea of what I am doing 
. I am hoping I can pull it off though
This should already work for Modify, Add and delete, both on IR and RF. Let me know if you see any issues. I did not do the learn option because it is a bit nested, and does not check result.
Yes, there is. First of all, I agree with you. I like it more the way you describe it from a user perspective. But it also creates the scenario where people can delete/overwrite/ commands without realizing, just because they forgot to set up a different command label. I build it as it is to overcome the limitations of the UI and avoid that situation.
Agree with name convention alignment.
Update: got the events subscription to work Will commit and push an update soon.
Update of the update; the issue seems that the events are only received for OSGI components. However, such components cannot have constructors with parameters (unless they are other referenced components). Hence, we have a problem, as we need the storage service and the UID of the channels.
I saw that earlier, and in the errors. I was looking into the different ways to inject the component (constructor vs field vs method), but i haven’t figured it out completeley yet.
I haven’t been able to get ahead much with this issue. I tried both constructor injection and method injection, both fail with the same error. Apparently, there is an osgi parameter init that allows you to define the number of arguments that the constructor uses, but it has not worked for me yet…
I managed to get the events to work, but then we just have another MappingService instance without any parameters being initialized. I want to try if we can make a singleton of the MappingService. This way we have one MappingService instance, who could then notify all the relevant channels.
I have been thinking about this, but I am not sure it solves the issue. From the singleton class, you still need to get all channels, and I have not found a way to query all things of type “Remote”.
My current exploration avenue is to add a public set to the BaseThingHandlerFactory level that contains a list of current thingIDs. Then, the notify…method in MappingService can just iterate through this list o update all pertinent channels.
The list would be updated when creating or deleting a thing, but i also need a way to get all things of type “Remote” on initialization, which is where i am stuck on (Basically, the same problem i would think i have with the singleton scenario.