Computer occupancy

[LeoS]

I'm slowly setting up my occupancy triggers with various devices and technologies for different rooms and activities... but this one should be pretty straightforward : desktop computers.

Has anyone scripted occupancy\events based on Computer login/suspend/sleep? I don't think pinging desktop computers work, especially Apple if you set them to monitor network activity that they can still share printers and files and while in sleep mode; they will still response to pings.

Moreover, if you use login/logout scripts, then you step up from just occupancy (anonymous) to presence (known identity), right?

So.. what to use? JSON? xAP?

[cheeryfool]

Not sure if this is exactly what you want, but Spud has a KB/Mouse activity plugin in the Utilities section of the Updater

[LeoS]

Oh that works too
Thanks!

[TomTom]

I think may be Jon00 has a script/plugin that you may find useful. Im not sure though but just checkout his plugins.


Tom

[Pete]

Here I utilize Jon00 scripts in Homeseer 2 to manage the Wintel XPe touchscreen clients. They suspend, screensaver, dim et al.

Integration with the Leviton HAI OmniPro II panel provides some occupancy stuff with the touchscreens and Jon's scripts.

[LeoS]

Thanks guys, unfortunately all of the solutions are for wintel whereas the desktops in question are macs. I think I'm gonna look into setting HS3 virtual occupancy device with JSON calls on system wakeup/suspend.

[Pete]

Sounds good there Leo.

I still utilize a bit of xAP / xPL here from a few years ago. It is well documented and you wouldn't have to re invent (proprietary) the wheel with some stuff.

I know it is old now but xAP / xPL is an automation network protocol sort of based on the basics of what computer networking is all about.


Message Structure (xPL)

All messages are made out of:

The message type (xpl-cmnd, xpl-stat or xpl-trig)
- The header block, inside curly braces, containing:
hop=n, the hop count which is incremented each time the xPL message is transferred from one physical network to another
source=vendor_id-device_id.instance_id, which serves to identify the sender of the message
target=vendor_id-device_id.instance_id, which serves to identify the destination of the message
- The message schema, in the format class.type
- The message body, inside curly braces, containing name=value pairs[6]

In the header block, the target name is replaced by the wildcard symbol "*" for broadcast messages. This is the case for tigger and status messages.

[LeoS]

Sounds good there Leo.

I still utilize a bit of xAP / xPL here from a few years ago. It is well documented and you wouldn't have to re invent (proprietary) the wheel with some stuff.

I know it is old now but xAP / xPL is an automation network protocol sort of based on the basics of what computer networking is all about.


Message Structure (xPL)

All messages are made out of:

The message type (xpl-cmnd, xpl-stat or xpl-trig)
- The header block, inside curly braces, containing:
hop=n, the hop count which is incremented each time the xPL message is transferred from one physical network to another
source=vendor_id-device_id.instance_id, which serves to identify the sender of the message
target=vendor_id-device_id.instance_id, which serves to identify the destination of the message
- The message schema, in the format class.type
- The message body, inside curly braces, containing name=value pairs[6]

In the header block, the target name is replaced by the wildcard symbol "*" for broadcast messages. This is the case for tigger and status messages.

Thanks Pete, I will be looking it up!

[Pete]

Relating to xAP....

A xAP enabled application (a xAPp) may be either a "sender", "receiver", or both. The xAP enabled device is connected to a communications network. Common communications networks include, but are not limited to: Ethernet ("computer" networks); RS232, RS485 serial networks; wireless.

As a sender, a xAPp broadcasts a message. This message contains sufficient information to uniquely identify the sender and the semantics of the message (the significance of the message contents - what the message actually means). Note that the message does not necessarily contain information which explicitly identifies an intended recipient, it only identifies the source itself.

As a receiver, a xAPp listens to broadcast messages. The receiver introspects the message (header) to identify whether the message contains information that is of specific interest to the receiver. Accordingly, the receiver then either discards the message or processes it.

It is possible for many receivers to intercept the same broadcast message concurrently. It is also possible for receivers to receive and process messages from more than one source. This allows for ad-hoc many-to-many relationships, on an implicit basis, without the need to configure explicit connections between various devices.

[LeoS]

Relating to xAP....

Hmm I dunno, Pete.

JSON calls are single line affairs... I just need to make one http call to HS3 server to switch the device I need.

I think I'll stick with JSON for this

http://homeseer.com/support/homeseer..._with_json.htm

In shell/terminal, just need to write this one line:

curl "https://usernameassword@homeseer-ip/JSON?request=controldevicebyvalue&ref=XXX&value=YYY"

replace username and password with yours
replace XXX with device #
replace YYY with value you want to change

Edit: Ok, done.
I used SleepWalker as the daemon to call the script during sleep/wakeup: http://www.bernhard-baehr.de

[Pete]

@Leo,

Just offering alternatives you mentioned.

I've tested JSON to work just fine here with Wintel clients along with remote control of Android clients via Homeseer 3.

[LeoS]

@Leo,

Just offering alternatives you mentioned.

I've tested JSON to work just fine here with Wintel clients along with remote control of Android clients via Homeseer 3.

Much appreciated