These work great… it sends the commands immediately to the Logitech Harmony hub and the device turns on/off as requested.
However, my persistence doesnt seem to be kept:
If I click the buttons they work… they may even show On/Off for a while, until I refresh the screen.
All my other persistence works fine. Im using MAPDB.
Ive never used Channels before in the above way, Ive always used Rules (which worked fine, but Im trying to improve/tidy up my setup and learn some new things).
I cant find anything on the forums/documentation. Is this how its supposed to work or am I missing something? I just want it to show the On or Off status as last pressed (or by testing ping to an IP address).
This has absolutely nothing to do with persistence. This has to do with how the sitemap displays the highlighting on the buttons. The highlighting is supposed to be based on the current state of the Item. So what is the state of the Item after you press it? Does it go to UNDEF or some other state shortly after being pressed?
Thanks for the reply. I did some logging and for the variable string PROJ, it says the State=UNDEF
So I think the answer to your question is a solid Yes… However, I have no way to test the device to see if its online/offline, because this is firing a remote command at a device through a Logitech Harmony (Infra red).
I had been using rules before, but found this method with Channel to operate much faster, hence the switch over to the Channel method.
Is there anything you can suggest, or should I switch back to Rules?
It’s a bit of a shame that the binding updates your Item to UNDEF when you know you aren’t expecting any feedback from the end device.
What you really need is a write-only channel, but this binding does not seem to offer that.
Perhaps that would be a useful enhancement to the binding - if the channel were write-only, openHABs autoupdate feature would store the last command string as your Item’s state.
If you look in your events.log, I suspect you will see this happen but then get overwritten by the binding’s UNDEF shortly afterwards.
I suppose there is some logic in the way it works now though; it’s like a button on a remote control - whether it is pressed or not tells you nothing about the controlled device (and it may be dangerous to assume).
So, if it can’t be fixed directly you’ll have to workaround.
I’d be inclined to use two Items. Keep your string to do the business, and add a Switch for UI control
I wouldn’t persist PROJ, pointless.
Put PROJSW on your sitemap
Switch item=PROJSW mappings=[ON="On", OFF="Off"]
PROJSW is likely to get out of step when you manually switch the projector, and at reboot, even if persisted. But the only harm from that is wrong UI button lit up.
Now we need a rule to make it work.
rule "do projector"
when
PROJSW received command
then
if (receivedCommand == ON) {
PROJ.sendCommand("PowerOn")
} else {
PROJ.sendCommand("PowerOff")
}
end
autoupdate will make PROJSW state reflect the last UI action
I did think that would be the situation. I was trying to avoid using rules because I was both tidying up my rules as they were a bit messy and also the rules engine was being a bit slow at times with some larger rules I have.
So Ive looked into increasing the threadpool counts in openhab over the last hour, which has provided some relief in rule processing speed… so I guess Ill just have to stick with using rules in some form for now, though Im with you, it would be nice to have the binding updated (and being able to send multiple commands on a single sendCommand line (as that would hugely shrink my rules).
There won’t be any measurable loading from that tiny rule, which only runs when you poke the UI button.
Take a hard look at persistence, only store what you need to store.
OH2 bindings are beginning to introduce new Actions, which allow you to directly send stuff to bindings from rules. Useful for something like sending sequences perhaps, if that’s what you mean.
Could be another useful binding enhancement.
Ill take a look at it. Even though Ive increased my Java memory, the thread count available to openhab, my cpu is running at 8% average (and usually hits about 20% max)… If I channel link what I want to do, as described at the top of this article, within under 1 second of pressing the button, my logitech harmony reacts and the button press is sent to the device its set to command.
On the other hand, if I send the exact same command through a rule, I can be waiting anywhere up to 20 seconds (sometimes it is instantaneous, but maybe one time in 3, even if I am sending the same command one after the next after the next e.g. send command… wait for it to operate the device… send it again… wait… send it again).
I dont have a huge rule file (perhaps 500 lines long and nothing complicated occurring).
So theres something snagging somewhere, though increasing my thread count and java memory did alleviate running longer rules.
I guess I will look out for the new Actions and see what comes of that.
As a general rule, you should not have any long running Rules. Anything longer than half a second is considered a long running Rule. There are tools and techniques available to avoid these in most cases.
I dont know why it crept in and became slow, but it has over various updates.
My Channel based setup at the top of this page is as mentioned, near instantaneous, however the following rule, which accomplishes the same thing, about 15 seconds before it kicks off:
rule "Projector On/Off"
when
Item PROJECTOR received command
then
switch (PROJECTOR.state.toString) {
case "ON" : { harmonyhub_device_yaj324324_51535350_buttonPress.sendCommand("PowerOn") }
case "OFF" : { harmonyhub_device_yaj324324_51535350_buttonPress.sendCommand("PowerOff") }
}
end
I believe this to be quite a clean rule (as most of mine are), so I cant see why the extra processing time.
Ive obviously looked for “slow processing rules” on here, which is what led me to upping my Java initial memory size and also the threadcount settings. This did alleviate things somewhat, Ive even uninstalled and reinstalled Openhab (without deleting the config files, though I guess I could try that too).
Have you any suggestions of word searches, articles or forum posts I can look at to understand the tools/techniques (as you say) to help me understand what I can do to diagnose the issues?
That rings alarm bells. You do understand that a command may or may not affect an Item’s state, and that if it does there is inevitably a short delay?
Triggering from a command and looking at state of same Item in a rule is usually indicating a race condition. There are some cunning ways to exploit command/state differences but this doesn’t really look like you are doing that.
But I understand the gist of what you are implying. What would you suggest? Make a new variable to pull in the state when PROJECTOR is changed and case that? e.g.
rule "Projector On/Off"
when
Item PROJECTOR received command
then
var NEWVARIABLE = PROJECTOR
switch (NEWVARIABLE.state.toString) {
case "ON" : { harmonyhub_device_yaj324324_51535350_buttonPress.sendCommand("PowerOn") }
case "OFF" : { harmonyhub_device_yaj324324_51535350_buttonPress.sendCommand("PowerOff") }
}
end
P.S. I am by no means an expert at coding… So any suggestions/advice would be welcome!
Well, where does this command come from? UI or rule I guess. You’re sending ON/OFF commands?
Just use the command, assuming you want to pass the command along to the target you are not really interested in its current state?
when
Item PROJECTOR received command
then
switch (receivedCommand) {
case ON : { harmonyhub_device_ ...
I’ve changed the case part on the assumption that PROJECTOR is a switch type with ON/OFF commands
Hi Rich, Ill have a check through that… Though I can confirm that since using the change that rossko57 recommended that things do seem to be much improved and running pretty much as they should be! (Which is a huge relief/blessing).
Though, I do have 1 oddity which might also be related in some way and I will be working to try figure whats going on. I have a relatively simple Logitech Harmony rule, which sends bluetooth Win+X, S and S to my computer (Basically puts my PC to sleep). All the commands are correct and it was a simple rule “when ITEM is changed to OFF… run these 3 logitech harmony commands… then end rule”…Its also the final rule in my rules file… which I dont think matters… but who knows.
I must have had some non-displayable character in the rule or something somewhere, as this rule would fail to trigger with any speed, mostly Id end up with it not working at all, or perhaps the 1st Win+X keypress… sometimes on the PC it would be infinitely pressing SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS etc…
After multiple things tried, I deleted all the spaces+tabs in between each command, put them back in and saved. And it started working fine again… no changed characters in the actual typed commands and the rule layout looked exactly the same format.
So Im beginning to suspect that I may have quite a few of these suspected hidden characters in my rules file as I copied/pasted often to create certain rules… and Im wondering if maybe Ive had a double impact of 1st using the Case statement incorrectly and also have something that whilst I cant see it, is tying up the rules engine/processes, putting the threads into an endless or long loop.
So Ill see if theres some easy way for me to find hidden/incorrect characters in the rules file… and also take a look through the link you suggest.
If I can 100% identify something, Ill feed back on here.
