Threshold Low , Threshold High , these would come under the
(2) "Triggered Event" that Gerry has mentioned ........
I don't think so - or at least not the way I read his description. "2) Triggered" sounds like, for example, every time the distance changes by more than 4 inches, send a message. What I'm describing is, again for example, send a message whenever something gets within 48 inches of the sensor. Then, send another message whenever there is nothing within 60 inches of the sensor. So, if something moves near the sensor a message will be sent. But, it will not continuously send messages. A message will be sent again when the object moves beyond 60 inches. By using high and low values here, you can avoid many messages when the object moving back and forth right around 48 inches.
As far as reporting all Sensor values in one message , im sure its doable , but if you only have a couple connected it would still have to report 00 for each sensor thats not connected..... I have a report ALL probes command in my Probe system but to be honest i never have used it as i only have 3 probes max on each zone currently....
I suppose having a report all command would be handy when a lot of Sensors are installed.....Looking forward to Gerrys comments on this........
I think this is valuable even when you only have a few sensors. If you are using interrupt driven communications on the PC end of things (such as having HomeSeer trigger whenever a certain string comes in to the serial port), it can be easier to just have this event triggered once and parse the data there. Otherwise, you will have to send multiple commands to query multiple sensors and handle multiple interrupts.
As far as the message protocol goes, are the reports sent from the device to the PC binary (bytes) or ASCII? I.e., in the report "$80SSVV" is it sending the characters "8" and "0" or is it sending the byte value 80? I guess I'm not sure if the "$" is a literal part of the message or if it's indicating that the rest of the stuff is in hex.
If the messages are not being sent as human-readable characters, then I'd suggest considering changing it so that they are. This makes it easier to debug - you can use hyperterminal - and often easier to handle programmatically.
If they are being sent as human-readable, I'd also suggest adding a terminating character - at least to the messages being sent from the device to the PC. A carriage return or line feed, for example, which would not occur in the normal message can greatly simplify handling messages on the PC side. In HomeSeer, for example, you can set up an event to trigger when a particular character is received. The entire message is then available for parsing. This saves you from needing to run an event every time a character is received and checking to see if you've received the complete message yet.
Edited by smee, 10 July 2006 - 07:07 AM.