HI, sorry for the presumably stupid question. I am trying to set up controls for a mediacenter PC. Start, mount/unmount/check status of a USB-Harddrive and such.
Unfortunately, no binding seems to be honored, not even the autoupdate=“false”. I also tried to reduce it to the minimum with just autoupdate, with the same result. openHABDesigner doesn’t show any errors and there is nothing in the logs except for reloads of items and sitemap.
What doe “not being honored” mean? It doesn’t work? Does nothing?
I strongly recommend simplifying and breaking this down into parts.
First of all get rid of the autoupdate=“false” . This overrides the default behavior and I don’t think it is warranted here. And I don’t know what you expect to happen if an Item only has autoupdate=“false” in the binding. That is just a flag so all you did was make an Item that isn’t bound to anything and therefore doesn’t do anything.
Second, split your bindings up into separate Items so you can see which one(s) are not working. Is the network health not reporting the status of 192.168.3.203 or is the exec binding failing?
Third, move the command line stuff out of the binding and instead of using the Exec binding use a rule with executeCommandLine(cmd, timeout in msec) so you can see what your commands are returning.
In almost every case the problem is a permissions problem (e.g. the openhab user isn’t in sudoers so your sudo systemctl call is awaiting entry of a password). This will show you those problems.
Yes, with not being honored I mean it doesn’t work. From the autoupdate=“false” I expect that the switch does not change status when it is clicked. In case of Mediacenter_Power, I expect changes only to happen from nh and in the case of Mediacenter_Dataext from the exec.
From this, I expect a switch that I cannot (visibly) interact with and that displays the online status of 192.168.3.203.
However, I still just get a switch that I can click and the status changes, and its state does not reflect the online status of 192.168.3.203.
If I didn’t understand autoupdate=“false” wrong, that is what I almost always want, if I am not controlling something that is REALLY reliable. If anything could happen to the execution, than I prefer getting the actual status update from an incoming state change.
First of all, not all bindings support autoupdate=false. It is completely possible that NH does not support it. You would have to look at the code.
Secondly, autoupdate = false only controls the behavior of the underlying binding, not the Sitemap. 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. All the autoupdate=false will do is change how the underlying bindings handle the received command. In this case I think the NH binding does nothing and allows the Switch to go to OFF.
What you probably really want to do is to put your NH Switch Item onto your Sitemap as a Text, not a Switch. If you use one of the ON/OFF icons (i.e. those that end in on.png and off.png) it will still change the icon to indicate the ON/OFF status of the Switch but you won’t be able to interact with it.
Ok, that makes sense, thanks. Though I was sure I had seen switches that do not change state when clicked. So this pushbutton https://github.com/openhab/openhab/wiki/Samples-Item-Definitions is always OFF, but the widget on the sitemap does not reflect that because it changes when clicked?
I am not sure how to elegantly model my system then. I want to display the status of the machine. If it is on, using some control should send the command to shut it down, if it is off, a control should allow to send a command to wake it up.
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.
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.
Have a switch with a state that corresponds to the online status of a machine
Clicking the switch should send the ON/OFF signal to the item, which then issues commands to the machine, but NOT change the state of the switch (since I do not want a false state if the on/off command fails). The actual state change is than performed by 1.
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"}
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:
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?
Try replacing the 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 replaced the whole command with /bin/ls for now, since I feel that I am currently far away from the point where the actual command matters. There is already a problem with autoupdate+nh (and even autoupdate alone), that is why I left the active parts out originally.
I did that. The switch still exhibits the same behavior. It does autoupdate and it’s state has nothing to do with the online state of of the mentioned IP.
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.
Be 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.
