Vera and the Multi Sensor

[Mark Johannessen]

FYI I just received a response from Vera that they are trying to fix
the Multisensor 6 issues in the next software release - but no
guarantees.

Mark

On Mon, Sep 14, 2015 at 7:11 AM, James Sentman <james at sentman.com> wrote:
>
>> On Sep 13, 2015, at 9:25 AM, Hendrik van Eeden <hvaneeden at comcast.net> wrote:
>>
>> batterylevel=100,humidity=70, temperature=19.3. light =10 and armedtripped=1.
>>
>
> //this thing is sending lots of confusing information
>
> (and heh, I just realized I put a comment // at the beginning of that last line, I’ve been writing a LOT of code lately ;) It’s starting to spill over into just typing emails…)
>
> {"altid":"28","id":"115","subcategory":"0","room":"0","parent":"1","armed":"1","batterylevel":"100","humidity":"70","temperature":"19.3","light":"10","state":"-1","comment":"","armedtripped":"1","lasttrip":"1442149717",”tripped","1”}
>
> normally in the Vera every device type has a “category” but this unit does not. And then the “subcategory” tells you which sensor or specific part of the device is doing the talking. This thing just has a 0 so no useful information.
>
> What that means is that i’m going to have to just break out the units into separate units myself. i can do that but it may lead to weirdness like the HVAC devices where you have a main unit that doesn’t do anything and a bunch of separate units that hold the actual data. I think in this case I can put the motion data into the main unit and the temp/humidity/light into separate ones. I shall experiment. The battery level will probably only show up in the “main” unit with the motion.
>
> Question for you though. It seems that there are 2 different reportings of the tripped state. The “armedtripped” that you mentioned above and the simple “tripped” at the very end of the packet there. I would like to infer that the armedtripped would only ever update if the device was armed and the tripped would change regardless? But how can we verify that? That ability to arm or disarm is to make the logic inside the Vera simpler for their popup action system. I dont think we want to not receive tripped information in XTension if the device is not armed in the Vera? Does that sound sensible? I think I will send an ON for the unit if it has either of those set to “1” or does that somehow strike you as wrong?
>
> I am going to support these, as I think mixed devices are going to get more and more common and this way if I get data for devices that don’t claim a proper category and subcategory i’ll just pull out whatever I find there that we know about. However you COULD now do it yourself with the new JSON data passthrough.  In case new devices come up that for some reason I do not want to support, or am taking too long to get the data out of for anybodies patience ;) an example would be to add a handler to the ON script of the unit that is created something like this:
>
>
> on JSONRequest( formData, JSONData)
> —formData will be empty under these conditions
> — must always put in try blocks as you’ll get error if the property isn’t there
> try
>   set myHumidity to humidity of JSONData
>   set value of “my humidity pseudo” to myHumidity
> on error
>   — no humidity
> end try
>
> try
>   set mylight to light of JSONData
>   set value of “mylight pseudo” to myLight
> end try
>
> end JSONRequest
>
> and so forth. Remember that if the key into the record turns out to be a reserved word in applescript, say there was one called “set” or something that would completely mess it up, you can surround the word in pipe characters to force applescript to recognize that it’s a key into the record and not to treat it as a language reserved word like:
>
> set mySet to |set| of JSONData
>
>
>
> Thanks,
>         James
>
>
> James Sentman                       http://sentman.com          http://MacHomeAutomation.com
>
>
>
> _______________________________________________
> XTensionList mailing list
> XTensionList at machomeautomation.com
> http://mail.machomeautomation.com/mailman/listinfo/xtensionlist