Abode Security System?

[paul]

That is why I am asking for examples of JSON for the devices that I do not have for my testing.

If you're still looking for more JSON examples, I'll definitely forward some on to you.

[Michael McSharry]

paul I believe BSR has provide a good set that should cover your devices.
BraveSirRobbin This additional data prompts some questions

The CAM has a control URL. (e.g. api/v1/cams/XF:123456/video) It also has three actions. I have interpreted the actions as the PUT or POST data to be sent to the control URL. Does this appear to you to be a reasonable assumption? I have seen similar with the Color Bulb with what I thought was an incomplete action set.

actions [3]

0 {2}

label : Capture Video

value : a=1&z=500&req=vid;

1 {2}

label : Turn off Live Video

value : a=1&z=500&privacy=on;

2 {2}

label : Turn on Live Video

value : a=1&z=500&privacy=off;

What raised question is when I saw your LM device that has four actions and four statuses, but no control URL. It looks like a sensor, but then what are the actions then other than what the sensor may report as an alarm state rather than as a control?

actions [4]

0 {2}

label : High Humidity Alarm

value : a=1&z=27&trigger=HMH;

1 {2}

label : Low Humidity Alarm

value : a=1&z=27&trigger=HML;

2 {2}

label : High Temperature Alarm

value : a=1&z=27&trigger=TSH;

3 {2}

label : Low Temperature Alarm

value : a=1&z=27&trigger=TSL;

statuses {4}

temperature : 58 °F

temp : 14.6

lux : 0 lx

humidity : 44 %

.
There are multiple device types that show their statuses as an empty array. The water sensor, siren, keypad and status display are some. I would expect to see some status reported when the water sensor detect water or when the siren sounds. One thought is that multiple status could be reported and it would populate the array with this feedback, otherwise the array remains null. Another thought is that status is only reported via the WebSocket so the Device properties will never be updated via the request channel. Does this seem reasonable or do have some other insight?

I don't know what to do with the keypad and status display. Not much information to help with the integration. Should I just exclude these?

[BraveSirRobbin]

That multi-sensor detects four elements, motion, light, humidity, and temperature.

I wouldn't worry about the camera, keypads, and remote siren (data wouldn't really be of any use in HomeSeer...at least for my purposes).

For the multi-sensor, it would be nice just to detect motion. I also have 'just' plain motion sensors as well.

Looking at paul's post, it seems we have identical desires for this plugin.

Looking at the camera on my phone...there are options (buttons) for sound, talk, image, and video. There is also a 'play' option for any recorded video.
I would think that if someone needed camera control they would just use the native app on their phone or computer.

Having the sensor status/changes for the door, window, and motions would allow integration with HomeSeer events. Arm status of the system (for HomeSeer events) would be good to have as well. Control to arm/disarm would not be needed, but would be a nice feature to be able to execute this with HomeSeer.

The leak detector would be nice to have as well for leak detection events in HomeSeer. Should I bring the Abode system to alarm for that sensor (leak detected) and re-run your JSON script extraction program while under this condition?

[Michael McSharry]

I now have the asynchronous event reporting working in a basic mode so I know I have overcome the authentication issues. Still more to do to make it robust. I think this is just a ping/pong type sequence so Abode knows we are still connected.

I am moving away from a polling concept other than at startup to identify the devices available and which HS Devices/Features to create. The event websocket will provide updates. This is primarily due to the lack of information about current & available status in the device polling endpoint. I expect to capture the fault information in a HS Device Feature. The event websocket reports if any faults exist. If one does exists then the devices endpoint will be queries to see which fault(s) exists.

Movement away from polling means that there is no need for anybody to collect data for a device when it is in the active/alarming state. What I would like to do is have the plugin learn the statuses that are returned in the event and then update HS Feature VSP to match what has been observed. This will provide more flexibility since HS does not do much with DeviceString and DeviceValue is needed for native event triggers.

At this point I do not have any obstacles of which I am aware. It is just a matter of progressing with what I know needs to be done.

[paul]

I am moving away from a polling concept other than at startup to identify the devices available and which HS Devices/Features to create. The event websocket will provide updates.

I can vouch that this will probably work well, I’ve been using the abodepy web socket to provide device updates on the fly and it’s been super reliable for years. I can count on one hand the number of times it got out of sync and that’s usually been because I was messing with something.

Thank you for your work on this, I’m looking forward to it!

[Michael McSharry]

I have started a new thread at https://forums.homeseer.com/new-content/1397617 to continue the plugin implementation of Abobe integration. I have done the implementation for both HS3 and HS4 with most of the testing using the HS4 plugin. I based the implementation on BSR's device set and did most of the testing with the items he provided.

What I noticed is that the Home Assistant and Hubitat implementation available on GitHub do not seem to be maintained as two of the four devices I am using for integration do not exist in either implementation. This will be a continuing problem as there is no public API and each device seems to have its unique integration characteristics. I am not setup to reverse engineer the encrypted communications and in general my attempts at following the pattern of prior devices from the two referenced implementations did not bear fruit.

I believe in the long term it will be easy to maintain new devices for status reporting in HS, but control of new devices from HS will be problematic.

There is implementation information from the two references for Abode devices that were not included with the HS plugin. I elected to go this route to keep in sync with the HS community's needs and not try to provide solutions for devices that nobody is using. If you have something that is not included then the provisions exists to collect the data so they can be included in the plugin with status reporting. Control of new devices via HS will be hit and miss.

I have been happy with the recovery from failure modes as the WebSocket implementation with a ping/pong handshake is effective to detect failures and then recover from them when the failure has been removed. There is much one-off type reporting and inconsistency in the interface. It reflects a product that is growing and initial concepts have been outgrown.

I did have a poor experience with the cam I ordered directly from Abode. No provisions exist in the order site to select the delivery carrier. They sent it USPS which does not deliver to my address. While I cancelled immediately after I learned of their delivery choice, it was a real struggle to get the refund. The customer support clearly had a directive to make the sale and every step of the way it was "I need to contact my support team". It was also annoying to have to answer survey questions before the original order was finalized.