Broadlink binding [4.1.0;4.2.0)

I guess the other question i have, even though it is probably a very basic one is, why can’t we just annotate all parameters of MappingService as References?

I have been trying all day / last evening to see if I could make the MappingService a component itself, as static classes are not allowed in the OSGI framework. However, I am now in the full OSGI dependency hell and I don’t know how to get out of it :frowning:

I think the best way to proceed for now is to accept the UI imperfection and move on and get the other things fixed first. What do you think?

Hello everybody! I can switch the aircon on and off through my sitemap:

Frame label="Aria condizionata Sottotetto"
  {
    Switch item=BroadlinkRM4Mini_Command
  }

Tried to run a rule which is sending commands to my RM4 mini

{
    sendCommand(BroadlinkRM4Mini_Command, Aircon_OFF)
}

But i get a error message:

Script execution of rule with UID ‘air_cond-2’ failed: The name ‘Aircon_OFF’ cannot be resolved to an item or type.

My broadlink map file is this:

Aircon_OFF=2600bc016d390d0f0d2b0d0f0e0f0c0f.....

How should I send the command in order to make it work?
Thanks!

I would say that you need to enclose Aircon_OFF in quotes, otherwise it gets interpreted as an Item name, which the error message tells that it doesn’t exist

I thing it is the sensible thing to do, even though i really wanted that feature. Do you want to make a list of the things that are left, and we can split them? wrote some down before, but most of them are not very important. The one that I think should make it through tough is adding the channel update on learning commands.

Do you have by any chance a branch you can share with the code with working events? (Even if it double instantiates) I just want to see how far i was, since i am trying to learn how osgi works.

Thanks!

The send command is done on the channel item. For example, if your channel item is Broadlink_RM3_Command:

Broadlink_RM3_Command.sendCommand("AC_ON")

At the top of the class:

@Component(service = EventSubscriber.class, property = {
        "service.pid=org.openhab.binding.broadlink.internal.BroadlinkMappingService" })
public class BroadlinkMappingService implements EventSubscriber {

and make sure you add a constructor without parameters or a constructor like this:

    @Activate
    public BroadlinkMappingService(
            final @Reference BroadlinkRemoteDynamicCommandDescriptionProvider commandDescriptionProvider,
            final @Reference StorageService storageService) {

Thanks! It worked also with the quotes!

Great! Thanks!

Can I also check the state with BroadlinkRM4Mini_Command.state == “Aircon_OFF” ?

I don’t think you can. The command channels are stateless. If you want to remember state, create an item to do so. For example, I have a simple Home_AC switch item, with the following rules:

// Turn off the AC
rule "Home_AC_OFF"
when
    Item Home_AC changed to OFF
then
    Broadlink_RM3_Command.sendCommand("AC_OFF")
end

// Turn on the AC
rule "Home_AC_ON"
when
    Item Home_AC changed to ON
then
    Broadlink_RM3_Command.sendCommand("AC_ON")
end

Great, that’s a good idea!

I made some changes for the following, but have not have the time to test them:

-Align Function Names for the RF and IR learning
-Improve channel messaging for UI, including learning.

These are the last changes i expect to make before considering this binding ready to merge as initial contribution (Unless lighting strikes and we get a breakthrough on automatic update of channel descriptions.). Will test and push tomorrow.
Thanks!

Hey @AntonJansen ,
Just provided an update for this with some good news.

-I found a way to update all command descriptions without using osgi Event model. I tested it already, it well.
-I have aligned the naming for IR and RF commands.
I have added some End user messaging on the channels, for better experience, when possible.
-I resolved some bugs.

I completely my local rm4pros branch, so for now, i uploaded the changes to a new branch, commanddescription_reload . I will clean that up tonight.

Any chance you can:
-Look at the automatic command reload feature, and tell me what you think.?
-Test the changes i made for messaging etc on the RF device, as i do not have one.?

Lastly, correct me if i am wrong, but in the RF devices, for each learning command available (Learn, modify, add), you both learn the command and make a storage modification? On IR, Only the learn command learns a code, the other 3 just make storage operations with the last learnt code. This is a difference in behavior that we should probably align, but it would be difficult to do with IR as the code is currently written in a way there is no return from a learn function, so it is not possible to know when it is completed.

Let me know what you think.

Thanks!

Hi @ricardol,

I will have some time on Sunday evening to work on the 2 requests from you. I will look at the automatic reload feature and test the RF stuff. I need to wrap it up quickly after Sunday, as I will be travelling on Friday the 19/4 for several weeks.

The issue with RF is that you need some break between the scan of the frequencies and the actual confirmation of the RF code to store. Let me see if I can merge them together once more, as we know have a better control through the command state to inform the user what is going on. It would be highly beneficial for RF to work kind of the same as IR.

@AntonJansen
I would expect, after this, we are done. Hopefully merged by 4.2M3?
Another question, are you ok to continue development on the commanddescription_reload branch instead of the rm4pros? I would expect, since we are close to stop changes, so we can merge, it wouldn’t be an issue?

Thanks

Hi @ricardol,

I have looked at the code and did some RF testing. The good news is that the RF works. I have merged the commandescription_reload branch with rm4pros. While going through the code there are the following things I need to fix:

  • Consolidate the code in the BroadlinkRemoteHandler to have no duplication between adding and updating a IR code
  • Merge the learning of the RF code with the first add / updating step
  • Clean up all the unneccessary logging. Openhab does not like logging. They only want it for errors / warnings.

I will continue tomorrow evening with coding.

Made another commit and push, the RF part is now finished. Fixed a bug with the wrong channel being used to communicate to the users. Next step is to clean up the generic IR handler and remove the logging that is no longer needed. Will continue tomorrow.

Hi! Where to find jar for openhab 4.1.3?

Hi,

The jars provided above should work for 4.1.3.