WOL with Ping Sensor

Plugins & Plugin Development General Plugin Discussion
#41

Tried EtherRain: same problem. Tried Virtual Switch: no problem.

I’ll add the additional data points to the bug report.

#42

Thanks all. For the record the plugin is working OK for me overall.

Edit: one thing I noticed, which does not impact me and perhaps there is a reason for it, is that when the On button is clicked, the light icon lights up for a short while and then goes off (presumably at the next ping time) but in any case long before the device is actually pingable. I have some devices like servers that may take 2-3 minutes to come up and become pingable. Is there a deliberate reason for this as it would seem to be counterintutive, IOW the light should not go on until the device is actually pingable.

#43

[quote=“bobk, post:42, topic:172491”]Thanks all. For the record the plugin is working OK for me overall.

Edit: one thing I noticed, which does not impact me and perhaps there is a reason for it, is that when the On button is clicked, the light icon lights up for a short while and then goes off (presumably at the next ping time) but in any case long before the device is actually pingable. I have some devices like servers that may take 2-3 minutes to come up and become pingable. Is there a deliberate reason for this as it would seem to be counterintutive, IOW the light should not go on until the device is actually pingable.[/quote]

This is because of the way the binary light device works under Vera. I am using this device to keep compatibility with 3rd party apps. When you click the on button, it sets the trigger and status values to 1. Since the boxes take longer than the next ping interval, it will than change that status to a zero as the box is not pingable. I have modified and created another version of the wol plus ping sensor to fix some of the issues that were discussed here. I’ll explain in the next post.

  • Garrett
#44

I have created another version of the wol plus ping sensor plugin to accommodate a few issues that were discussed in this forum. The new plugin will probably break compatibility with 3rd party apps like homebuddy, sqremote, etc. Testing needs to be done by others on this forum to see if it is compatibile with the other apps against the new version. I will attach the files. Some changes:

  • The trigger and status events are separate from each other. So they can be scripted differently in scenes. In order to make this happen, I had to create a new device type which may break compatibility with other 3rd party apps. However, I am using the binary light service variables and assigned it the same category of a binary light. It functions with out modifications in my android app (AutHomation). The only downside to this is that the status and trigger can become out of sync. Meaning that if you turn the device on via the plugin, the trigger and status state will change to 1. However, if you turn the device off physically, the status will change to a 0 and the trigger will remain as 1. I have not figured a good way to correct this. This limitation is due to having the events separate. If you have any suggestions, let me know.

  • The device state will only change when the status of the ping changes. In other words, when clicking on the on button, the status to on will only change once the device is pingable. The same goes for off.

If you have the market version installed, you will need to remove that plugin in order to install this version. Let me know how it works out. If all goes well, I’ll update the market version with the new plugin.

  • Garrett
#45

Good step forward. I wish you could keep the standard API.

I’m using HomeWave as my remote app now. And it works perfectly with the combo switch and virtual switch. Do a a code compare against them.

#46

I am well familiar with both of those plugins. I believe that the developer of HomeWave added support for those plugins. As I have stated earlier there is no way to work around the custom device type issue and have the separate events. If the new plugin is to be accepted, the other developers will need to add support for them.

  • Garrett
#47

I’ll test this when I get home.

#48

7:40pm: Documenting my process.

[ol][li]Downloaded the files in the post.[/li]
[li]Saved UI5 backup to home share.[/li]
[li]Uploaded files to UI5 (overwrite old ones that were still there even though plug-in not installed)
(Checked restart luup)[/li]
[li]Stopped here, could not find a way to install the device. Doesn’t show up anywhere. Investigating…[/li]
[li]Installed old plug-in so it could be removed. Files may have been left behind after previous restore.[/li]
[li]Uninstalled plug-in. Files were still left behind.[/li]
[li]Re-uploaded files as before.[/li][/ol]

Still could not find a way to install this.
So, stopped again. I’m not in a rush, so I’d prefer some guidance on how to appropriately proceed.

#49

You need to install the plugin through Apps> Develop apps>Create Device

Follow steps 3 and 4 from this wiki page: http://wiki.micasaverde.com/index.php/Install_LUUP_Plugins

#50

Thanks strangely for the instructions.

  • Garrett
#51

I will resume installation tomorrow.

#52

Okay… So far nothing weird happening. Works with VeraMobile! (But not with Homewave :()
One issue though:
It looks like when I flipped the switch ON, it turned the state to on (didn’t do this with OFF).
And then in my case the computer takes who knows how long till a valid ping is returned, and then switches to off again, and eventually back on. This is with your default 60 seconds.

I know that it’s nice to see the switch change state immediately, but in truth the state should not change to ON until the ping actually succeeds. It’s a tough one because you’d like to give the user immediate feedback, but you can’t be sure.

#53

[quote=“electricessence, post:52, topic:172491”]Okay… So far nothing weird happening. Works with VeraMobile! (But not with Homewave :()
One issue though:
It looks like when I flipped the switch ON, it turned the state to on (didn’t do this with OFF).
And then in my case the computer takes who knows how long till a valid ping is returned, and then switches to off again, and eventually back on. This is with your default 60 seconds.

I know that it’s nice to see the switch change state immediately, but in truth the state should not change to ON until the ping actually succeeds. It’s a tough one because you’d like to give the user immediate feedback, but you can’t be sure.[/quote]

This is not the intended case. The state should not have turned to on immediately. It should have remained off until the state changed. If you read my post above about the changes in this new version, I mentioned this very feature. So either something is wrong in my code (i’ll double check as it was working fine for me) or something is weird with your configuration.

  • Garrett
#54

Just checked and things are working as they should. When pressing the on button, it will send the wake-on-lan command to the computer and will not set the status of the device to “on” until the computer is pingable. The same happens when pressing the off button, the status status stays to “on” until the computer is not pingable anymore. So it looks like something is not write in your configuration.

  • Garrett
#55

I triggered it from VeraMobile so it must be it that’s doing that.

I’ll check it again a bit later in UI5.

#56

Please do so we can narrow down the bugs.

  • Garrett
#57

Works as expected. I didn’t test the status change events. But in UI5 it did exactly as I expected.

#58

Okay. So again, I had to restore my setup.
After wiring up the OFF button trigger to initiate hibernate, and then turning off my computer for the night, it would no longer stay on. After about 10-15 seconds of being fully on and responsive, it would then hibernate again.

Here are some things to consider and watch out for…
Not necessarily your fault, could just be Vera being stupid:

  • When I removed the device it still left behind the hibernate trigger!
  • When I removed the trigger, it STILL TRIGGERED THE HIBERNATE! WTF!?
    … That’s why I had to do a restore.

I think I’m gonna back off from this for now, too much trouble and risk for my system. I think if someone doesn’t wire up to the off button, then this will do exactly what it says. Displays the status, and triggers WOL for the on button. But there is something still very wrong.

#59

I do not know why you are having so many issues. I am not experiencing any of these problems. The plugin does not have control of removing the triggers. That is done by Vera. The off button functions perfectly and has been reliable for me.

  • Garrett
#60

Garret, how do you have your off button configured.
Is your computer only going to “sleep” mode?
If it’s behaving as I think it is, sleep verses hibernate will exhibit a different chain of events. Waking from sleep is near instant. Hibernate responds to WOL just like sleep but takes a full boot cycle. Therefore giving the plugin a chance to drop from ON to OFF (missed ping) and triggering (if not possibly queueing) the hibernate code. If I wired the trigger only to the sensor state, then this is almost expected behavior. But I wired it to your newly provided off button trigger.

The other issues are clearly Vera. I just felt it important to point them out because it’s probably the result of installing the plug in manually.