Does anyone see anything that can be wrong in that code? I use it for other devices (lamps, etc) and it works with no issues.
One thing that crossed my mind is, the amount of double quotes the command has could be causing the command to be misinterpreted. I tried to escape the douible quotes with \, but got the same result. Anyone knows how can i escape characters in this command safely? Alternatively, is there a way that i can map string to the commands in order to avoid using the full IR code in the habPanel page code?. That would also be much cleaner.
What do you see in the logs? Is the item receiving a command at all? Is there an error?
I guess it’s been nearly 10 years since I’ve used habPanel so there’s only so much advice I can give there. The snippet looks like it should work.
This is the better way to go, in my opinion, anyway. There are several different options for this which only differ in some technical details which you probably don’t have to worry about.
You should be able to create a map transform and apply that to the item → thing direction on the thing or link configuration.
Depending on the details of the differences in the payload json for each command there are other transforms that may work as well or better than map, e.g., regex or jsonpath.
This sounds like it might just be a good candidate for a rule with a proxy item. That is, you create a string item that is not linked to the channel and send commands to that item. Then you have a rule that triggers when the proxy item receives a command and translates the command into the payload which is then sent to tasmota_ir_6D5A38_IRSEND.
What do you see in the logs? Is the item receiving a command at all? Is there an error?
I don’t see anything. I actually don’t see any HABPanel related logs. I’t does not look like the command makes it to the item, which makes me wonder what kind of issue is happening within HAPanel
You should be able to create a map transform and apply that to the item → thing direction on the thing or link configuration.
I actually have a map file created for this. But my understanding was that map transforms only work thing←item. Any chance you can point me to documentation that shows how to do the inverse?
This sounds like it might just be a good candidate for a rule with a proxy item.
Yes, this could be a solution, but i was wondering what is the best way to implement this. I would prefer that the rule has as little code as possible and its just a table lookup. I haven’t seen any examples of this use case. My other concern is adding delay to the ir command, which is something that i am trying to avoid.
This depends on the binding you are using. Some bindings, such as MQTT (which I assume is what you are using) have special configurations for this. With MQTT you go to your thing and then configure the specific channel you want to configure. In the channel configuration page there is an “Advanced options” check box. Select that and you will see that you can set different transforms for incoming and outgoing values.
Indeed, the rule would not have to be much more complicated than that. Any of the rules languages should be up to the task (even blockly would work pretty well for this). I use JSScripting for most of my rules so a reference object with string keys and output values would be trivial and of course, handling the final JSON format for the output is native and easy.
I do not think you will ever detect a difference. Any issue that is going to cause that simple rule to slow down will almost certainly be systemic and therefore also impact transform functions etc. If you are on an older OH4 version or before, you might have an issue where the first run of a rule on a bare minimum sytem is very slow, but any version from the last year or so won’t even have that slow down.
That is the outgoing transformation in the configuration page I mentioned. In this case outgoing means from OH (i.e., item) through the channel to the device (thing). So if you have a transform that takes the string and creates the payload you want then that transform goes in the outgoing transform config. Then sending a string to the item linked to that channel will cause the string to be converted to the payload before that payload is sent out to the MQTT topic. The item state will remain whatever string you set it to but what your MQTT broker gets will be the transformed payload.
