Emergency or priority trigger

The python client has a socket listener / serial interface that might do the trick - how does your particular fire alarm work? I would imagine that it would be a serial interface where a switch opens / closes. Have a look at this (http://wiki.xibo.org.uk/wiki/Interactive_Lift_Devices_Project_Specification) for more information.

The windows client doesn't have either of the above two things at the moment, although we might add them in the future.

The fire system will give me a dry contact per zone in alarm, so the hardware side of things is easy to implement. I was hoping that there was a web service or similar on the content controller side of things, so I could use one "alert call" to set all the displays in a group (or number of groups depending on how the fire zones mapped to display groups) to "priority" all at once. It would be even better if I could remotely change the content of the groups to match what sort of alarm I am given.

The elevator project seems to be the way to control individual displays by actions/events at the display, which is not really what I am trying to do.

If the functionality of what I need does not exist, I'm happy to start having a look at adding some functionality to the backend, if there are any pointers available on how the back end is architected.

thanks

Hi Ross

Firstly, priority - in Xibo terms - is about overriding the currently scheduled layouts for a period of time with a more important schedule. It will always override, not just when some other input is set on the client. So I don't think it's really applicable to what you want now.

The lift support in the Python client is closest. It listens to a serial port for inputs going from high to low or low to high and changes the content being shown based on that input.

It also has a socket listener which could easily be extended to support the lift inputs - so then you could write a little application that read the inputs from your fire alarm and then connected to your client machines and sent the appropriate commands to activate a particular layout.

The windows client has none of that stuff, so if you want to use with the Windows client you'd need to begin by implementing those two things.

Cheers

Alex

You could look at adding some methods to the API - so that you could schedule a layout to a display group when your fire alarm went off, and then delete the schedule when it was cleared.

If you did it this way there would be a delay as each clients collection interval expired.

Alex's suggestion would be better in terms of responsiveness - implementing a socket listener in the Windows client probably wouldn't be that hard.

Thanks for the feedback. It was Dan's approach that I was looking at, perhaps I need to combine the two.
Is there an API that gets me all the displays in a group - I don't want to have to keep (yet another) list somewhere of what display is in what group so that in an emergency I know what displays to contact. I prefer to keep a master source of info in one place and just reference it when needed - the display controller already has that list so why duplicate it.
Because of the licencing costs for the windows client, I'm looking at the unix client anyway - really looking forward to a functional android client when it appears, the small android/hdmi/media player/802.11 client devices that look like a large USB stick would be perfect.

The API is still very sketchy as it is still heavily in development, you will need to be using 1.3.3 - check out http://wiki.xibo.org.uk/wiki/XiboAPI.

The oAuth implementation is done and tested to be well, as are a few of the methods for uploading files. As I've said to other people, I am happy to add methods to the API on request and can add the DisplayList / DisplayGroupList methods for you if you are serious about building your app.

Ross had a great line of questions for functions I can see to use in a number of ways. Has any progress been made on this and in the API?

Hi thumper
I didn't progress this because we bogged down finding a suitable display controller - Windows clients were too expensive for the customer, unix clients were unstable, and the android client didn't exist at the time. Whilst the android client now exists, their licensing model for disconnected clients (i.e. not internet connected - this particular customer has limited/intermittent internet connectivity) was prohibitive. When the client side of things settles down a bit more, we might revisit this requirement.

I know this is an old thread but is there any news on emergency takeover of displays now for version 1.7 ?

Assuming a blueprint was filed then that will have the answer. If no
blueprint was filed then nothing will happen