23 Commits

Author SHA1 Message Date
25acdd9481 Add documentation v0.0.1 2025-01-04 12:27:44 -06:00
ab4898c20b Add pings, debug logs, socket cleanup to Unit
At some point I need to stress-test this to see how long the connection can stay open, and what happens when it goes down.
2025-01-04 12:05:29 -06:00
5ae6cac549 Add ability to subscribe for updates to properties
Using SubscribeToUpdates() will cause the Unit to trigger a "notify" event any time the subscribed property changes, containing the new value of the property.

I don't know how/if you can unsubscribe from something as I don't see the official app ever doing that.
2025-01-04 11:22:12 -06:00
40b3c2dc98 Add GetSchedule message 2025-01-04 10:47:12 -06:00
60e57afea2 Add more fields, documentation 2025-01-04 10:46:32 -06:00
834086160d Add directory to ignored files for formatter 2025-01-04 10:45:51 -06:00
905cb83310 Satisfy linter 2025-01-03 20:30:15 -06:00
e306a62e24 Add messages, cleanup
This adds a bunch of messages to retrieve and set various things on the controller. It also groups the messages under one export to simplify the process of using and discovering many of them from one location.

Some of these are WIP/probably not portable to other systems.

This also adds the ability to set multiple circuits at once.
2025-01-03 20:27:30 -06:00
7daf47ac18 Fleshing out more messages
Getting a feel for how the development experience is with this setup. With the previous idea of abstracting the request into a getSystemInfo() function on the Unit itself, the documentation for what to expect from GetSystemInfo either had to live in two places or be presented as a link to the canonical location. Neither felt great, so I think the caller can just call send(GetRequest()) themselves.

Also added the first "set" message which is capable of toggling a body or circuit.
2025-01-03 16:01:58 -06:00
ceb9299d03 Create Unit class to make queries easy 2025-01-03 14:58:31 -06:00
0c946505b0 Use existing variable for request type 2025-01-03 13:57:36 -06:00
c7e2ab7675 Initial request/response object structure
No idea if this will be the best way to represent this stuff long-term, but it's working at the moment. I have some reservations about attempting to list all the possible ResponseParam keys, but I'm already this far in and it would be nice if it worked out...
2025-01-03 10:57:54 -06:00
b186561d24 Finish Finder implementation
This can correctly find and return IntelliCenter units on the local network now.

Cleaned up a bunch of Finder code and added back in "debug" module logging.

Fixed up types in Dns module so we can use instanceof
2025-01-02 17:03:28 -06:00
4ccdf837d9 Give artifact unique name per job 2025-01-02 15:27:40 -06:00
a885e3fb2c Update dist files 2025-01-02 15:20:44 -06:00
74a91c2e13 Minor fixes
Add a field for the raw ipv4 address of an A record (encoded in an int)
Rename "remaining data" to "rdata" since that's what the dns spec calls it
Update Srv record rdata block to be handled the same as other records
Fix A record endOffset to have the correct value
2025-01-02 15:20:02 -06:00
6d8258313d Ignore macOS junk 2025-01-02 12:04:12 -06:00
d43a958cfe WIP: DNS response parsing 2025-01-02 12:03:57 -06:00
41cdaba05c WIP: IntelliCenter controller locating
This is capable of broadcasting the request and receiving the response, but is not yet decoding the responses to identify the appropriate one that is the controller. That is forthcoming, and documentation is on the wiki.
2025-01-01 11:47:51 -06:00
942a03aea1 Move types package to dev dependencies 2025-01-01 11:45:09 -06:00
eaf660ea77 Add Wireshark capture of find request/response 2025-01-01 11:43:17 -06:00
d25cd56d0c Add mitmproxy log
This should help with implementation by providing a reference of what the official app does.
2024-12-31 21:40:41 -06:00
73d968bb3b Initial commit
Proof of concept of websocket connection to an IntelliCenter controller.

I swear it takes longer to get the linters setup and cooperating with each other than any of the actual code...
2024-12-31 11:26:43 -06:00