Sky+ IP Control

Completely ignore my last post and tidied up code. I've messed up the classes when tidying the indentation - most of the functions should be in the upnp class but I've taken them outside.

I'll come back to it later - I've got the class importing and functions calling manually, but cos I messed up it's doing nothing it should do.

(I've not done much with classes in any language, so I'm learning that bit on the fly, along with python!)

Peter

Durosity, how would you envisage connecting Sky's serial port to Indigo in your setting? Onboard serial port (Mac), remote PC/Mac adjacent to Sky box with serial port, or iTach RS232/IP/Wifi box?

One of mine has a PC next to it which would send the data over IP for free; the other would need iTach.

Peter

My sky box sits in my server rack so is available via a local rs 232 port. Looking forward to your results with this little project... Even just being able to determine if the sky box is on or not will be a massive help (I hate devices with no discrete on / off ir codes)

Right, having some success now!

Got the script working from the python shell as designed; it finds my Sky+HD box and allows me to control it interactively.

I understand the flow of the commands through the script, I'm just trying to decide at which point (if any) I could call into it from outside as-is, or whether I need to add additional logic to it to take external input.

When you run it interactively, it searches for Sky boxes and stores any found hosts in an array, which the 'Save' command allows you to save to file for re-use later. Next time you run it, if you call it with -s to load the saved file, it does so, then goes searching for boxes again - I've inserted an if() to stop it searching if I've told it to reload saved data for now. (Need to add debugging in case the saved data is no longer valid such as a new Sky box or changed endpoints on a firmware upgrade, but for now it's ok)

Unfortunately once you've found the hosts (either searching of by -s) it drops into it's own interactive command line awaiting commands (control play, control pause) - need to find a way to send commands such as skyRemote.send("play") without it complaining variables haven't been instantiated because I'm not using their main() method.

Peter

You might want to organize the plugin so that on startup, and perhaps as an action, it searches for Sky boxes and stores any found hosts in plugin-properties. If there is typically just one box per location, that would be fine. On the other hand, if there could be multiple boxes, you might look at the device factory model. I have no experience with the factory model, but I think it would do what you want.

To handle all this in a plugin, you could do something like:

• In deviceStartComm() call into the sky code to populate your box(es) into properties and then have the code return control back to plugin.py. So, instead of waiting for command line input, the code could just quit.
• In runConcurrentThread() just loop, with a 0.5 or so, second pause waiting for events to be fired or action requests to be received

It is hard to be more detailed because I am nit clear exactly what this plugin is supposed to control or report.

You might want to organize the plugin so that on startup, and perhaps as an action, it searches for Sky boxes and stores any found hosts in plugin-properties. If there is typically just one box per location, that would be fine. On the other hand, if there could be multiple boxes, you might look at the device factory model. I have no experience with the factory model, but I think it would do what you want.

Yeah, that's basically what I'm aiming for - but as one or more devices with an on/off state and serial no property, not plugin-properties.

To handle all this in a plugin, you could do something like:
In deviceStartComm() call into the sky code to populate your box(es) into properties and then have the code return control back to plugin.py. So, instead of waiting for command line input, the code could just quit.

As well as showing the on/off state, the device(s) will be the target for actions (SkyRemote actions > Send command: Device [x], Command [y]) in case there are more than one box. (I have two, but the second is still in its box until I've finished watching a recorded series on the old non-HD box). I'll also have to use the save() and load() functionality in the existing code to save the host details to file, because it stores a huge array of data, not just IP address or serial no - but as you say, call this on startup and shutdown, as well as an action/menu item.

Is the factory model an Indigo concept or Python concept - I've not heard of it in either, but presumably Indigo?

In runConcurrentThread() just loop, with a 0.5 or so, second pause waiting for events to be fired or action requests to be received

That's what I wasn't sure of last night - if I needed runConcurrentThread() to pro-actively monitor for events/actions, or whether Indigo would call one of my methods when one of my actions was executed, allowing me to process it accordingly.

I'm aiming to have the additional methods in the Sky code done tonight, to a point that I can call everything from the command line that I'm anticipating the plugin calling, rather than the current embedded calls within 'self'. myMain(), mySearchHosts(), mySave(), myLoad(), mySendCommand(), etc. If I get those done quick enough, I might even create a basic plugin with a bunch of test buttons within the plugin's configUI dialog box.

Peter

...Is the factory model an Indigo concept or Python concept - I've not heard of it in either, but presumably Indigo?

It is Indigo. Check out the example in the plugin SDK.

... if I needed runConcurrentThread() to pro-actively monitor for events/actions, or whether Indigo would call one of my methods when one of my actions was executed, allowing me to process it accordingly.

You just sit and spin and Indigo will callback to the plugin using the documented method for action handling.

Sounds like you are making real progress!

[jay (support)]

An object factory is a well known design pattern in object-oriented systems. In Indigo, the Device Factory is a way to create a device config dialog that can create a variety of different devices (or even multiple devices). The thinking here is that some things have the ability to be discovered in some way: for Z-Wave, we discover new devices by asking the Z-Stick for a list of devices that have been included into the network, then we compare that to the devices that we already know about, and finally we can present a list of "new" devices to add inside the Device Factory dialog. The Device Factory is also used in the Vera Bridge and ISY plugins (as I recall) - so the dialog opens and we ask the Vera/ISY for a list of available devices.

The other, more standard way of creating a device is for the user to select a specific device type then open the config for that device type. It works in those circumstances where the user knows the device type they're trying to add (weather station, iTunes server) and there are only a few options. The Device Factory saves the user from having to do that - they just see a nice list of available devices to add and the right thing just happens.

The Device Factory saves the user from having to do that - they just see a nice list of available devices to add and the right thing just happens.

So (basically) if I used the Sky code above to search for Sky Boxes on the network, I could use a Device Factory to populate a list and say to the user "Here are the Sky boxes on your network; please add which ever one(s) you want to be able to control using Indigo"?

Peter

[jay (support)]

Exactly. Sometimes there's a delay while "looking" for discoverable devices (network latency, discovery protocol, etc.) so you might need to start the process when the plugin starts (and periodically thereafter) so the user doesn't have to wait for it when they open the factory dialog.

But, yes - discover the Sky+ devices, compare that to any devices that have already been created, then show only the devices that haven't been defined in Indigo.

Thanks Jay.

Peter

Sounds like you are making real progress!

Yep...

Code: Select all

import skyRemote
myHP = skyRemote.myMain()
skyRemote.mySearch(myHP)
skyRemote.mySave(myHP)
skyRemote.myLoad(myHP)
skyRemote.myHosts(myHP)
skyRemote.mySendCmdStr(myHP,0,"Pause")
skyRemote.mySendCmdArr(myHP,0,"Play")

Woohoo, it works!

Added a few methods to the bottom of the original skyRemote.py, imported it to python and executed those commands.

myMain() initialises the network socket listener thingymabob ready to send/receive SOAP.
mySearch() listens for SSDP broadcasts and adds the Sky ones into an array.
mySave() saves the list of hosts to file for recall in a future session
myLoad() loads in the saved list of hosts from file.
myHosts() echos them to the screen for reading purpose.
mySendCmdStr() sends a single-valued command such as "Pause" - that doesn't need additional parameters.
mySendCmdArr() isn't finished, but it will send a command that needs additional parameters, such as "Play" - that needs a speed parameter.

The '0' in the commands is the host ID, in case you have more than one Sky box; host ID 0 is the first one it finds, but the script will send to any.
I presume 'HP' in the original scripts is Host Process (the socket/listener), so I've carried it on for now.

Now for the plugin....

Peter

Not had much time tonight, but I've merged the mySendCmd*() functions into one, so I can send a single or multiple parameter command from the same function - I just pass additional parameters in an array where needed. The code isn't returning errors, but I can't check the Sky box because our guests are watching the TV at the moment - I've been sending the 'play at normal speed' command which obviously doesn't affect their viewing.

I've included the deviceName and serviceName variables into the method call in case Sky changes them in future - if I make those properties of the plugin Sky+ Device, I can expose them as disabled text fields in the customUI, dependant on a 'overwrite parameters' checkbox. Thus if Sky make changes, users can modify them manually until I or someone else updates the defaults in the script and republishes the plugin.

Might not get back to this until midweek now.

Code: Select all

myArgs = {}
myArgs['InstanceID'] = ('0','ui4')
skyRemote.mySendCmd(myHP,0,'SkyControl','SkyPlay','Pause',myArgs)

myArgs = {}
myArgs['InstanceID'] = ('0','ui4')
myArgs['Speed'] = ('1','string')
skyRemote.mySendCmd(myHP,0,'SkyControl','SkyPlay','Play',myArgs)

Peter

I'm very excited by this... Looking forward to the final result.


Sent from my iPad using Tapatalk

Right..

Pre-release version 0.0.1 is now ready - it simply finds Sky boxes on the network and populates a 'Sky+HD Box' device with the details, then (still in the Device definition) has temporary buttons to Play and Pause the device. These buttons will move elsewhere in due course, but I just wanted to get the basic function working within Indigo world.

Durosity, are you in a position to test it? If so (and this applies to anyone else) - PM me and I'll send you a link to it and instructions.

Peter

Yep, I'll send you a message!


Sent from my iPad using Tapatalk