After searching these forums and Google for quite some time, I found numerous examples of TPI scripts using java, C#, perl, etc. but nothing in PHP. I have tried, unsuccessfully, to create a simple webpage that could read the status of the alarm, zones, etc. Perhaps at some point I'd like to add the ability to arm/disarm, but for now just reading zone statuses.
I understand there is a site delivered with the module that shows all of this, but I'm just building something in my spare time to play around with.
Does anyone, anywhere, have a PHP example of how to communication with the Envisalink?
Thanks in advance!
Justin
TPI for PHP
Moderators: EyezOnRich, GrandWizard
-
tinkerfailure
- Posts: 3
- Joined: Thu Oct 11, 2012 6:04 am
- Contact:
Re: TPI for PHP
Hi Justin,
I'm in a similar situation to you. There doesn't seem to be much out there regarding PHP. I installed my Envisalink 3 yesterday, and have been finding my way around the online portal thing. The plan, however, was always to make my own.
It seems to me that the best way of cracking it would be to use C#, but I'm only really proficient in PHP. Given the difficulty of picking up C#, I reckoned I'd start with PHP and then maybe learn C# in the future.
So my plan was to create a simple 'listener' that would maintain the persistent connection to the Envisalink. This would then basically parrot each event out as a Server Sent Event stream that I could subscribe to with my PHP based 'dashboard' app for controlling the house. I'd probably want to log every event in a mySQL database too.
I'm thinking it would be best for me to run the PHP 'listener' as a daemon, so as not to miss any events from the Envisalink.
Then (and this is the bit I haven't worked out yet!), have some sort of 'control' script that oversees the stream coming from the 'listener' and then perform some automation tasks (lights, heating etc) based on various logic criteria.
I'd love to know more about the kind of thing you're working on.
And let me know if you get any pointers from anyone else.
Cheers
C
I'm in a similar situation to you. There doesn't seem to be much out there regarding PHP. I installed my Envisalink 3 yesterday, and have been finding my way around the online portal thing. The plan, however, was always to make my own.
It seems to me that the best way of cracking it would be to use C#, but I'm only really proficient in PHP. Given the difficulty of picking up C#, I reckoned I'd start with PHP and then maybe learn C# in the future.
So my plan was to create a simple 'listener' that would maintain the persistent connection to the Envisalink. This would then basically parrot each event out as a Server Sent Event stream that I could subscribe to with my PHP based 'dashboard' app for controlling the house. I'd probably want to log every event in a mySQL database too.
I'm thinking it would be best for me to run the PHP 'listener' as a daemon, so as not to miss any events from the Envisalink.
Then (and this is the bit I haven't worked out yet!), have some sort of 'control' script that oversees the stream coming from the 'listener' and then perform some automation tasks (lights, heating etc) based on various logic criteria.
I'd love to know more about the kind of thing you're working on.
And let me know if you get any pointers from anyone else.
Cheers
C
Re: TPI for PHP
Web pages are stateless, unless you want to query and wait for a response for ever zone and partition on the module php talking directly to the module is not the way to go.
What you want is a middleware layer that talks to the module and keeps state, such as some front end to a database, then php simply queries the database and interacts with that.
What you want is a middleware layer that talks to the module and keeps state, such as some front end to a database, then php simply queries the database and interacts with that.
Jon Pounder
Re: TPI for PHP
The concept of a daemon is pretty much the only way to go I can see.
When something happens the daemon can
a) Act on it
b) Post to a url the event
The daemon can be
i) php script (not preferable as memory issues and generally php is not clean when run to be a daemon)
ii) some other script
iii) windows executable / linux executable
I think b + iii is the best/easiest approach. It leaves the majority of the complex functionality to the web service (php, asp, js, ruby, whatever). However it means having to run a daemon app somewhere to maintain a connection to the envisalink, if it goes down/crashes then its bad (but this can be mitigated with other tools that act as a watchdog).
Whats your opinion ?
When something happens the daemon can
a) Act on it
b) Post to a url the event
The daemon can be
i) php script (not preferable as memory issues and generally php is not clean when run to be a daemon)
ii) some other script
iii) windows executable / linux executable
I think b + iii is the best/easiest approach. It leaves the majority of the complex functionality to the web service (php, asp, js, ruby, whatever). However it means having to run a daemon app somewhere to maintain a connection to the envisalink, if it goes down/crashes then its bad (but this can be mitigated with other tools that act as a watchdog).
Whats your opinion ?
Re: TPI for PHP
I would write it in C, and definitely a daemon.
Desktop windows is pretty much out of the question for a daemon that has to keep state of anything and play nice with others, too much interference from reboots all the time and windows firewall getting in the way anytime it wants to do anything.
I would keep the state of the system in a database, postgres is my personal preference but sqlite is ok when minimal hardware such as a linux based router is available.
Postgres allows you to put any logic in the database itself and execute it based on changes of state from triggers, then you don't have to recompile anything to implement new logic as long as your i/o piece was designed properly.
At its simplest form the daemon could just be a command formatter pipeline, assume any incoming command is parsed off the wire for validity and inserted into an incoming table, from there triggers take over, process the command and update any of the actual state representing tables you have in your schema which can be queried by outside things like php in the normal way. To send a command or response the other way triggers would be set on an outgoing table and any time a row is inserted they would format up the checksum etc, and send it out over the wire.
Desktop windows is pretty much out of the question for a daemon that has to keep state of anything and play nice with others, too much interference from reboots all the time and windows firewall getting in the way anytime it wants to do anything.
I would keep the state of the system in a database, postgres is my personal preference but sqlite is ok when minimal hardware such as a linux based router is available.
Postgres allows you to put any logic in the database itself and execute it based on changes of state from triggers, then you don't have to recompile anything to implement new logic as long as your i/o piece was designed properly.
At its simplest form the daemon could just be a command formatter pipeline, assume any incoming command is parsed off the wire for validity and inserted into an incoming table, from there triggers take over, process the command and update any of the actual state representing tables you have in your schema which can be queried by outside things like php in the normal way. To send a command or response the other way triggers would be set on an outgoing table and any time a row is inserted they would format up the checksum etc, and send it out over the wire.
Jon Pounder