Skip to content

update to reflect the "latest unofficial" protocol#1

Open
mrose17 wants to merge 5 commits intochadsmith:masterfrom
TheThingSystem:master
Open

update to reflect the "latest unofficial" protocol#1
mrose17 wants to merge 5 commits intochadsmith:masterfrom
TheThingSystem:master

Conversation

@mrose17
Copy link
Copy Markdown

@mrose17 mrose17 commented Jul 28, 2014

i have reviewed the other packages by:

and then updated this package to reflect a “best hits” approach.

the changes:
1 headers: send User-Agent using brand from login response
2. parameters: use latest appId: and always send filterOn:
3. responses: look at both body.Message and body.ErrorMessage for error
messages
4. make sure logged in before attempting to retrieve devices, et. al.
5. keep track of longevity of security token, refreshing as needed
6. use latest paths (all lower-case, slightly different paths)
7. and the big one:

the return value on getDevices is flattened tree structure. first,
identify locations that are associated with gateways; then, identify
subordinate devices that are associated with garage doors.

note that in some cases “bogus” devices are returned (probably due to
incomplete registrations). in order to cull these, the
deviceRecord.response attribute, if present, is consulted to see if a
device is actually extant.

mrose17 added 5 commits July 27, 2014 17:38
i have reviewed the other packages by

@adamheinmiller - https://github.com/adamheinmiller/ST_MyQ
@pfeffed - https://github.com/pfeffed/liftmaster_myq

and then updated this package to reflect a “best hits” approach.

the changes:
1 headers: send User-Agent using brand from login response
2. parameters: use latest appId: and always send filterOn:
3. responses: look at both body.Message and body.ErrorMessage for error
messages
4. make sure logged in before attempting to retrieve devices, et. al.
5. keep track of longevity of security token, refreshing as needed
6. use latest paths (all lower-case, slightly different paths)
7. and the big one:

the return value on getDevices is flattened tree structure. first,
identify locations that are associated with gateways; then, identify
subordinate devices that are associated with garage doors.

note that in some cases “bogus” devices are returned (probably due to
incomplete registrations). in order to cull these, the
deviceRecord.response attribute, if present, is consulted to see if a
device is actually extant.
fix PUT for setDoorState, also return self for prototypes to support
chaining
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant