[Solved]Cannot retrieve item for widget

Hello
I’m new to openhab and I’m trying to get some test items working. I can make items and sitemaps; however, I can’t seem to actually get anything to output into the realworld.
In general my issue is that I cannot seem to send udp packets nor wol packets (focusing on getting a simple wol example working first)

wol refrence: https://github.com/openhab/openhab/wiki/Wake-on-LAN-Binding-(WoL)

my setup
I do not have any .rules, scrips, or transform files
addons installed to /openhab/addons all from 1.8.0

action: mqtt,
bindings: mqtt, http, serial, tcp, weather, wol

test.Items. I got a couple more commented out with //.

Switch mywolPC “wolpc” {wol=“192.168.1.255#00:1f:d0:93:f8:b7” }`

test.sitemap

sitemap test label=“test sitemap”
{
Frame label=“MyStuff” {
Switch item=mywolPC label=">wol"
}
}

My output when i click on the switch

2016-01-24 21:33:03.903 [DEBUG] [.io.net.http.SecureHttpContext] - checking ip is in range took 0ms
2016-01-24 21:33:03.905 [DEBUG] [.io.net.http.SecureHttpContext] - security is disabled - processing aborted!
2016-01-24 21:33:04.230 [DEBUG] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item null for widget org.openhab.model.sitemap.Frame
2016-01-24 21:33:04.254 [DEBUG] [.io.net.http.SecureHttpContext] - checking ip is in range took 0ms
2016-01-24 21:33:04.256 [DEBUG] [.io.net.http.SecureHttpContext] - security is disabled - processing aborted!
2016-01-24 21:33:04.257 [DEBUG] [.o.u.w.i.servlet.WebAppServlet] - Servlet request received!
2016-01-24 21:33:04.265 [DEBUG] [.o.u.w.i.servlet.WebAppServlet] - reading sitemap test

Any tips advice. I might have more than one error going on. I’m still trying to figure out the syntax of everything.
Thank you

If this MAC address refers to a Windows PC, does this comment at the bottom of the wiki page apply?

Note: For windows computers not in a Domain the firewall must be configured properly (allow remote shutdowns) and the DWORD-Regkey LocalAccountTokenFilterPolicy in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System must be set to 1.

Also, I assume the target is on the 192.168.1/24 network?

Possibly
My network computers and devices are on 192.168.2.1-192.168.2.249
My main computer and server are already set up for wol magic packets and working.

I have an app on my phone that i’ve been using. To test beyond looking down the hall and seeing if the server actually turned on, i’m using a wol packet sniffer from: https://www.apreltech.com/Free/Wake_on_lan_Packet_Sniffer
Granted this sniffer runs on port 9 but i’m assuming the openhab wol setup isnt working since the server never turns on in the first place.

So I dont think its a firewall issue, but I could be mistaken.
Rereading your post, the reference is referring to remote shutdown not wakeup

Ah yes; sorry. Are you able to see your sitemap at http://YOUROHSERVERADDRESS:8080/openhab.app?sitemap=test

And a switch labelled “>wol” that you can turn ON?

You could add a rule file called rules/test.rules (or call it anything.rules)?

rule LogSwitch
when
  Item mywolPC received command
then
  logInfo("LogSwitch", "My switch was turned " + receivedCommand.toString)
end

just to confirm the commands are getting to the item?

Yes I can see and interact with the sitemap both on the phone app and website.
So just wrote that rule in. Where does it show up? the openhab.log file?
If so It didn’t show up.

Still getting the Cannot retrieve item null for widget org.openhab.model.sitemap.Frame

Just a random idea that your label in the sitemap label=">wol" is confusing the client. Could you remove that from the sitemap (in which case it will use the "wolpc" label defined for the item)?

…Oh, and the > in your Frame label is also suspect. Remove that, too.

now its Switch item=mywolPC label="wakeonlan"
No change in behavior.

The > came from the forum’s block post. Had some issues getting it to format. Edited out.

I will try this item/sitemap on my test setup and tell you what I see. Give me a minute…

For refrence
This was installed on a raspberry pi 2 with this tutorial. http://www.makeuseof.com/tag/getting-started-openhab-home-automation-raspberry-pi/

I also have these lines in the logback.xml file (there’s a < at the beginning of each line)

logger name="org.openhab" level="DEBUG"/>
logger name="org.openhab.binding.tcp" level="DEBUG"/>
logger name="org.openhab.binding.wol" level="DEBUG"/>
logger name="org.openhab.binding.weather" level="DEBUG"/>
logger name="org.openhab.binding.mqtt" level="DEBUG"/>

I dont know if there are any others that would be helpful

I bet that’s the root cause of the problem. These 3rd-party tutorials have so often led to issues.

If you instead followed the official installation instructions here, you would probably be in a better starting position. Specifically, use apt-get to install all packages.

I just tested the following on an RPi2 running Raspbian Jessie, and it behaved correctly, except for actually waking up a PC, since I haven’t installed the wol binding.

items/test.items:

Switch mywolPC "wolpc" { wol="192.168.1.255#00:1f:d0:93:f8:b7" }

sitemaps/test.sitemap:

sitemap test label="test sitemap"
{
  Frame label="MyStuff" {
    Switch item=mywolPC
  }
}

rules/test.rules:

rule LogSwitch
when
  Item mywolPC received command
then
  logInfo("LogSwitch", "My switch was turned " + receivedCommand.toString)
end

produces lines in log/openhab.log:

2016-01-25 06:29:16.345 [INFO ] [openhab.model.script.LogSwitch] - My switch was turned ON
2016-01-25 06:29:35.788 [INFO ] [openhab.model.script.LogSwitch] - My switch was turned OFF

Looking at the two toutorials they are almost identical both use the apt-get method.

Also I manualy copied the addons from the large zip file instead of using the apt-get command to get the bindings.

The only difference between the two was this line:
Curiously, everything was installed as owned by “root”. We need to fix that with the following commands.

sudo chown -hR openhab:openhab /etc/openhab
sudo chown -hR openhab:openhab /usr/share/openhab

which makes sense unless openhab needs be owned by root.


Sadly your files are identical with mine. And I virtual copied the wol example from the wiki.

The only thing that comes to mind is I created these files with ‘sudo nano test.items’ then changed owner to openhab:openhab. Could this relate to this issue: https://github.com/openhab/openhab/issues/670

Nothing jumps out at me regarding your file permissions choices. It would make sense to use

sudo apt-get install openhab-addon-binding-wol

etc. instead of copying the JARs, but again, should not matter in this situation.

Is there anything odd about how your RPi resolves hostnames, routes on the network, or anything notable about its networking configuration? Also, anything “non-Western” about your default locale on the RPi?

This is a mystery…

This is a standard (US) home network. I used a clean raspberian image then installed openhab.
Granted the default local of the pi is UK but I changed that in software. Ill look again.

However before my pi arrived I was playing around with a virtual linux machine configured as a bridge connection(not NAT). I was having the same issue where neither udp packets nor wol were doing anything.

Suppose i could go back to the virtualbox wipe and try again.

I think this message is a red herring – the reason it’s DEBUG is because it doesn’t really matter. Its only point is to say there is no item= on your Frame widget, which is normal.

The real question to me would be why you don’t get INFO lines in the log when you added the test.rules file I offered. Re-read your version of it, make sure the file permissions are correct, use the touch command to get openHAB to reload it, see it reloaded in the openhab.log file, toggle, the Switch, and try to get the INFO lines logged.

Ok so update. I went back to a Virtual machine and did a clean install of openhab via the guide here. The only difference I can see is that i used the apt-get method of installing the bindings instead of copying them.

GOOD HAPPY NEWS wol switch works. Your info rule prints out and the wol sniffer is catching the magic packet. :grinning:

2016-01-25 20:17:14.112 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:15.125 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:16.141 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:17.152 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:18.163 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:19.172 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:20.181 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:21.022 [INFO ] [inding.wol.internal.WolBinding] - Wake-on-LAN packet sent [broadcastIp=192.168.2.255, macaddress=001fd093f8b7]
2016-01-25 20:17:21.037 [INFO ] [openhab.model.script.LogSwitch] - My switch was turned ON
2016-01-25 20:17:21.198 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:22.209 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:23.120 [INFO ] [openhab.model.script.LogSwitch] - My switch was turned OFF
2016-01-25 20:17:23.219 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:24.234 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:25.244 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:26.255 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe
2016-01-25 20:17:27.267 [INFO ] [b.s.i.n.typicals.RefreshHEALTY] - sendHEALTY_REQUESTframe

Now question. Where are these sendHEALTY_REQUESTframe coming from and how can I remove them. They’re nice to see but they spam the log file.

1 Like

It’s a defect in the Soulliss binding that logs these messages at INFO level. You can suppress these log entries by adding

<logger name="org.openhab.binding.souliss.internal.network.typicals.RefreshHEALTY" level="WARN"/>

(or higher level) to your logback.xml file. We must have missed this in a review process somewhere along the line.

Thank you for all the help :slight_smile:

1 Like