Design Philosophy - TeamPracticalProjects/SISProject GitHub Wiki

The Client and the Hub operate a bit independently. They share some common assumptions. For instance, the Hub expects certain sensor positions to be PIRs and others to be separation sensors; the Client must obey these assumptions. The Client expects that an code for an unconfigured sensor will be logged with the work "unknown" in the string; the Hub must obey this. We need to do a better job of documenting these all in one place.

The Client has the internal array of a structure of sensor attributes. One attribute is the label that is displayed on the Client GUI. Another attribute is the label that will be passed to the Hub when that sensor code is registered in the Hub. We were very worried about memory usage in the Hub and thus the labels given to the Hub are shorter and less easily readable; the labels used in the Client GUI can be more expansive.

Communication between the Hub and Client is also limited by the number of functions and variables that Particle will allow any one Photon to expose. Particle also imposes limits on how long the names of these functions and variables may be, the data types that can be passed, and the length of strings that are passed.

One way to design the interaction between the Client and the Hub would be to make a very compact, binary representation that is exchanged. This would let us pack more information in each call. However, this would also make it impossible to interact with the Hub except through some kind of Client software. We wanted to make it possible for a human to examine and easily understand the data that is sent and received from the Hub. This makes it possible to look at the data transferred using the browser Javascript console and understand it. We discussed using JSON to represent the transferred data, but the overhead caused the string lengths to exceed what Particle allows.

In the client we could certainly have the Client read a configuration from a JSON formatted file. The current design is to have the different client configurations present in the JS code itself. The configuration data is all located in one place. We've separated the view from the code; it's not a bad idea to isolate the configuration from the code. However, this would require the JS or the HTML read a file from a file system. One design criteria was for the JS to run completely in a browser without a need to interact with a host. From a separation of function standpoint we could still pull out the Client configuration into a JSON file, but then the browser would have to make a second call to the host to retrieve the configuration file. It seems like more work that I think it is worth at this point. A user will still have to host all this on their own system to customize it.

The senor trip data in the Particle cloud is ephemeral. Each Spark.publish has a Time To Live and when that expires the published message is gone. A service that wants the data, like IFTTT, must poll the Particle cloud faster than the TTL. I don't think there is any way to query the Particle cloud for old data. Our model is to hold 100 events in the Hub and then retrieve them from the Hub to display them. Or have them stored in the Google Docs Spreadsheet for longer term analysis.

The Particle cloud provides Server Side Events, which is just a long lived HTTP connection. A client can open a connection and subscribe to an event stream. The Particle cloud will send keep alive messages periodically. When a qualified event is published the client will receive it. I have written some code in the Client to establish this connection and display the results, but I found it difficult to maintain the connection for more that 10 minutes. It is on my to-do list to find a way to monitor the connection and re-open it if it closes. Then as sensors are tripped the Client will display an indicator so a user can see it work. It is cool to have the Client open in a browser and walk around the home watching each sensor label in the Client turn green for an instant after the sensor is tripped.

The caregiver or other user of the SIS has to be somewhat technical. They must interact with the Particle configuration, IFTTT, the Client code, and they have to solder and debug their own SIS Hub. We've tried to make it easy to do. The SIS today is not for an end user type. In my experience it is even a bit difficult to use the Client web site to correctly register the sensors; one must keep their wits about them.

I hope the Javascript was understandable. This was my first experience with JS. I read a book and jumped in. I have since learned to hate JS ;-). It's lack of strong typing and insistence on the functional program model drives me nuts. Scoping of variables is difficult and there are even cases where variable scope is ambiguous; I wouldn't have believed it if I hadn't read it in a book. I tried my best to be clean and clear, but things have a way of getting out of hand. It has been suggested to move to TypeScript; I haven't looked at that yet.