afaik autoupdate="false" will prevent the openHAB item to change it’s state through changes, triggered from UI, so if you are using a button at your sitemap:
Switch item=myButton mappings=[ON="Start!"]
the button will stay released, even if you press the button, but will send an ON to the bindings bound to myButton.
That is how I understood it, but if I understand correctly, rikoshak claims otherwise:
When you put a Switch on your sitemap you will always get a Toggle controller and if you manually click on that toggle it will turn OFF or ON.
Fact is, my sitemap that loads this item
Group Mediacenter
Switch Mediacenter_Power_Passiv "Dataext Power Passiv" (Mediacenter) { autoupdate="false", nh="192.168.3.203" }
via its group gives me a switch that does not reflect the online status of 192.168.3.203 and is changeable via clicking.
When you use a group to render the items in the group, you don’t have the benefit of the sitemap to control the widgets used to render the items. You would have to explicitly include the switch item in the sitemap, and possibly use Text item=Mediacenter_Power_Passiv label="Dataext Power Passiv [%s]" to render it in the sitemap as a read-only widget (no UI button is going to make sense for monitoring the network presence of that IP). But if you later add wake-on-lan control (or turning on a Z-Wave power switch or however you power it on), using a Switch widget could make sense.
Yes, that is exactly what I want to do:
So, while 2. is not implemented yet, I don’t see a reason why the switch on my sitemap is changeable by clicking (and why nh doesn’t seem to do anything). That is what I ask. The switch I see does not expose any behavior from the {} part, but it DOES have the description from the item (since I am loading it from the group), so it obviously is related to the item description.
Let me give a full example:
Group Mediacenter
Switch Mediacenter_Power_Active "Dataext Power Passiv" (Mediacenter) { autoupdate="false", nh="192.168.3.203", exec=">[OFF:systemctl -H sshcommander@192.168.3.203 suspend -i]", wol="192.168.3.255#00:1f:d0:93:f8:b7"}
and
sitemap mediacenter label="Mediacenter"
{
Frame {
Group item=Mediacenter label="Mediacenter"
}
}
Should this work in the way I described (given that openhab and sshcommander have the necessary permissions and certficates) or is there an error?
{ nh="192.168.3.203" }
How are you going to do that? Use a binding like wake-on-lan, or some other binding that turns on a relay, or have a script trigger on Item Mediacenter_Power_Passiv received command ON?
{ autoupdate="false" }
The Network Health binding only reports on the accessibility of an IP address, but doesn’t change the powered state of devices. You would need something like:
{ nh="192.168.3.203", zwave="12", autoupdate="false" }
To have the item update when the IP is reachable, have ON/OFF commands you send go to a device that will turn it on or off (or use the wake-on-LAN binding or some other binding), and not update the switch when you press the ON/OFF buttons, instead only relying on the Network Health binding to update the item’s state.
I just looked at the source to the Network Health binding and there was nothing I could see that would interfere with normal autoupdate="false" behavior.
Hi, watou, I do understand all that. That’s why I wrote I haven’t implemented the active component yet and called my Item _Passiv. If you look back at my previous posting now, you see the full implementation as I imagine it.
The thing is: Nothing of the stuff in the curly brackets has any effect on my UI. It’s like it wasn’t there.
I KNOW that the UI loads this Item, because it has the description and everything (that is why I load it via the group, so no information is introduced by the sitemap) but none of the bindings work.
I assumed some syntax error or stupidity on my side, but it doesn’t seem to be that easy, apparently. There is also nothing in the events.log about this item. The MQTT stuff for my garage door works fine though, status updates are shown in the log every 60 seconds.
If nobody sees an obvious error in my code, could someone perhaps test the item and the sitemap?
My only two commens about the full example you posted above are:
Group item=... in the sitemap with a Switch item=... just to see if the switch behaves differently depending on where it appears in the sitemap.I don’t think that sitemap is the issue. As far as I see, even without any sitemap, I should see the results of nh in the events.log. That is not the case, though. Something seems to make the whole {}-part functionless.
New insight: While the UI state of the button does change, any clicking on the button, be it from of to on or vice versa, produces an ON command:
Mediacenter_Power_Active received command ON
If I remove the autoupdate=“false”, I get alternating
Mediacenter_Power_Active received command ON
Mediacenter_Power_Active received command OFF
Still no apparent result from nh, neither in the sitemap, not in the events.log
Did you copy/move the addons to the addons-folder?
Appears so:
root@home-le:/usr/share/openhab/addons# ls /usr/share/openhab/addons
org.openhab.binding.exec-1.8.2.jar org.openhab.binding.mqtt-1.8.2.jar org.openhab.binding.ntp-1.8.2.jar org.openhab.binding.wol-1.8.2.jar org.openhab.persistence.logging-1.8.2.jar README
org.openhab.binding.http-1.8.2.jar org.openhab.binding.networkhealth-1.8.2.jar org.openhab.binding.samsungtv- 1.8.2.jar org.openhab.persistence.exec-1.8.2.jar org.openhab.persistence.rrd4j-1.8.2.jarBe aware that the networkhealth binding does no ICMP ping, maybe you have to setup a port that responds to nh’s test (I had to do this for my tv). Did you setup a refresh interval in openhab.cfg? Default is 60 seconds, so maybe you’re only too impatient 
The binding page says it only uses echo on TCP port 7 if openhab is not allowed to do ICMP ping. I don’t see a reason to believe that. At least a ping as the openhab user on the shell works fine.
But guess what, I took a shot and reinstalled openhab-addon-binding-networkhealth and suddenly events start to show up. I’m still not fully satisfied, since autoupdate doesn’t work and I have to reload the page for the switch to update (the icon of my garage door changes almost immediately without reloading) but this is at least a huge step.
That could be caused by a known issue in OH 1 where the sitemap elements do not always refresh. Watch the events.log. If you are seeing ON and OFF events there then everything is working and the sitemap is just not keeping up.
NOTE: This has been fixed in OH 2. It will not be fixed in OH 1.
Yes, the event.log updates fine. Guess I’ll have to wait for OH2 then. Is there any roadmap when we can expect a beta?
So apparently, the whole thing was a combination of this update-bug, possibly the way networkhealth handles autoupdate and an apparently broken networkhealth installation.
Thanks to all of you for the help.
OH 2 is already in its second beta release.
Oh, nice. Am I also overlooking a Ubuntu/Debian repository?
Yes for OH 1. No for OH 2. You still have to manually download and install OH 2.
The OH1 one I found, I am using that. Ok, I’ll see when I have time to do the manual install. Thanks again,
See this just posted thread when you do have time.