@Jean34, I have the Broadlink RM3 Pro Plus, and I can see it in Discover devices.
You might have some useful logs?
Otherwise, for information, I use the same library as the one from the Gladys V3 module.
Hello, after rebooting the pi, it did find my RM Pro 3, cool.
Then I configure the buttons of the remote control that I want, by testing via the button it works well, but on the other hand the remote control does not appear in the Gladys interface. I tried quickly last night and I couldnât look into it more than that⊠And I leave for vacation tomorrow so if I have 10 minutes Iâll check the Gladys and browser logs to provide them to you⊠Of course I tried on Mozilla and Chrome.
I love good news 
Did you add the box on the dashboard?
Hello
I took the time to test the TV remote control part
It works perfectly 
except for one detail for my TV there are 2 different buttons for turning on and off and nothing is provided on the remote control for it seems
Otherwise, do you plan a model type air conditioning? Mine is controllable (like most) via RF and with Gladys 3 I controlled it with the broad module
Thanks
Edit waiting for the other model I use the lamp one in detournement for the air conditioning so it also works 
Yes, I think I have activated it⊠Do I need to configure all the buttons to make it appear?
No, one is enough.
Hello @AlexTrovato
Where is this integration as well as the broadlink service?
It needs to be completely reviewed to try to improve the remote control devices. Donât rush.
Iâm not in a hurry ^^, I just find it a shame that the information is not transmitted on each post .
When I read the comments, it seems that we are well advanced and this information is from 7 months ago ..
Hence my question.
On the other hand, you did not answer me regarding the Broadlink service.
Are you doing something about it?
Lol ok, I didnât see that your sentence had 2 parts, because a service on the v4 is also named integration. So nothing to evolve, neither the broadlink features, nor its preparation for merging into the v4.
From what I remember, the idea was to be able to manage a lamp with broadlink like other lamps are managed. But I think it will be complicated to match a classic lamp with an IR remote-controlled lamp.
Broadlink in progress⊠for the others, have fun 
@pierre-gilles Iâm resuming the discussion we started on the PR z2m Fix zigbee2mqtt set value by atrovato · Pull Request #1383 · GladysAssistant/Gladys · GitHub
The question is: what is the most appropriate way to store the mapping between the values of Gladys features and the values (here) to be sent to the Broadlink module?
Today, in the Broadlink service currently being finalized, I use the device.params to store the values of the feature actions.
I end up with a lot of params related to features.
The example I exploit in demo mode (knowing that the values are long IR codes - unreadable character strings):
{
"name": "TV Remote",
"model": "television",
"selector": "broadlink-8008bda3ae44",
"external_id": "broadlink:8008bda3ae44",
"should_poll": false,
"poll_frequency": null,
"created_at": "2019-02-12T07:49:07.556Z",
"updated_at": "2019-02-12T07:49:07.556Z",
"features": [
{
"name": "Power",
"external_id": "broadlink:8008bda3ae44:binary",
"selector": "broadlink-8008bda3ae44-binary",
"category": "television",
"type": "binary",
"min": 0,
"max": 1,
"read_only": false,
"has_feedback": true
},
{
"name": "Source",
"external_id": "broadlink:8008bda3ae44:source",
"selector": "broadlink-8008bda3ae44-source",
"category": "television",
"type": "source",
"min": 0,
"max": 1,
"read_only": false,
"has_feedback": true
},
{
"name": "Channel",
"external_id": "broadlink:8008bda3ae44:channel",
"selector": "broadlink-8008bda3ae44-channel",
"category": "television",
"type": "channel",
"min": 0,
"max": 1,
"read_only": false,
"has_feedback": true
}
],
"params": [
{
"name": "peripheral",
"value": "8008bda3ae44"
},
{
"name": "code_binary-1",
"value": "POWER"
},
{
"name": "code_source",
"value": "SOURCE"
},
{
"name": "code_channel-0",
"value": "CHANNEL_0"
},
{
"name": "code_channel-1",
"value": "CHANNEL_1"
},
{
"name": "code_channel-2",
"value": "CHANNEL_2"
},
{
"name": "code_channel-3",
"value": "CHANNEL_3"
},
{
"name": "code_channel-4",
"value": "CHANNEL_4"
},
{
"name": "code_channel-5",
"value": "CHANNEL_5"
},
{
"name": "code_channel-6",
"value": "CHANNEL_6"
}
]
}
Here is the current status.
Now I wonder if it would not be more readable to bring these values closer to the features rather than to the devices, for example:
{
"name": "TV Remote",
"model": "television",
"selector": "broadlink-8008bda3ae44",
"external_id": "broadlink:8008bda3ae44",
"should_poll": false,
"poll_frequency": null,
"created_at": "2019-02-12T07:49:07.556Z",
"updated_at": "2019-02-12T07:49:07.556Z",
"features": [
{
"name": "Power",
"external_id": "broadlink:8008bda3ae44:binary",
"selector": "broadlink-8008bda3ae44-binary",
"category": "television",
"type": "binary",
"min": 0,
"max": 1,
"read_only": false,
"has_feedback": true,
"value_mapping": {
"1": "POWER"
}
},
{
"name": "Source",
"external_id": "broadlink:8008bda3ae44:source",
"selector": "broadlink-8008bda3ae44-source",
"category": "television",
"type": "source",
"min": 0,
"max": 1,
"read_only": false,
"has_feedback": true,
"value_mapping": {
"default": "SOURCE"
}
},
{
"name": "Channel",
"external_id": "broadlink:8008bda3ae44:channel",
"selector": "broadlink-8008bda3ae44-channel",
"category": "television",
"type": "channel",
"min": 0,
"max": 1,
"read_only": false,
"has_feedback": true,
"value_mapping": {
"0": "CHANNEL_0",
"1": "CHANNEL_1",
"2": "CHANNEL_2",
"3": "CHANNEL_3",
"4": "CHANNEL_4",
"5": "CHANNEL_5",
"6": "CHANNEL_6"
}
}
],
"params": [
{
"name": "peripheral",
"value": "8008bda3ae44"
}
]
}
Letâs talk about it 
Iâll take up my comment from the PR then: why isnât it stored in the code?
How does Broadlink work?
@AlexTrovato I just saw your message on Github, I understand better now.
Dumb question, why isnât this the job of the « external_id »?
In most integrations, the external_id is the « external » identifier.
After all, that presupposes that a feature = an IR message⊠not crazy.
Ok no, now (Iâm thinking as I type :p)
Actually, what scares me about creating a mapping in device_feature is two things:
- For now, I feel like we havenât had many cases that require this kind of dynamic mapping, and I want to make sure I understand all the cases we can have before implementing a generic solution (because when you code a DB function in SQLite, no going back).
- The JSON fields in the DB created by the integrations, that scares me a lot The validation must be ultra solid on the core side. Besides, now that I think about it, it doesnât necessarily have to be stored in JSON mode, it could be stored relationally (device_feature_mapping).
If thatâs just what scares you, I donât see the problem on my side.
For me, the main reason to switch to feature-based storage would be if we have cases of feature collisions (if feature A and feature B need the same mapping but with different values), otherwise I think storage in the params is the most suitable and the most robust (itâs stored properly in relational, itâs solid on the core side).
Itâs true that modifying the DB isnât ideal.
And in JSON even lessâŠ
Letâs stay in this mode for now, if the need becomes stronger, weâll think about it again.
Sounds good to me!
Do you plan to add categories, like for air conditioners, light bulbs, etc.?
Or will we be able to do it in Gladys?
How will this be implemented for an air conditioner remote with
- temperature +
- temperature -
- fan +
- fan -
- mode: air conditioning, heating, ventilation, etc.
I think he thought more in terms of TV media style.
In my opinion, what youâre asking for is a different need 