Commit Graph

10 Commits

Author SHA1 Message Date
c445a844ee Split into commonjs and ESM outputs
This allows require() and import to work for even better compatibility between CJS and ESM consumers.

I dislike that this kills our ability for top-level awaits in example.ts, but seeing as how my primary use case for this library is a commonjs module, I think this is a fair trade-off.

Also changed "messages" to not encapsulate its export under the name "messages" to remove some repetition in importing "messages" and still needing to do "messages." to get the methods out. Now it's simple to import each message by name or group them under something like "messages" as desired on a per-library-user basis.

Refs:
* https://www.kravchyk.com/typescript-npm-package-json-exports/
* https://arethetypeswrong.github.io/
* https://evertpot.com/universal-commonjs-esm-typescript-packages/
2025-01-05 15:34:07 -06:00
50d71a2858 Add GetCircuitStatus message 2025-01-05 11:59:03 -06:00
abe9ba7d95 Rename Item to Object
The API all calls these objects so best to go with the flow.

This is a breaking change.
2025-01-05 11:56:53 -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
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
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