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)
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
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.
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.
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.
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 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.
