This is from my earlier notes, hope it helps some.
Pin 1: RS422 +/B
Pin 2: RS422 -/A
Pin 3: ? - appears to be unused; connected to unpopulated pad on PCB
Pin 4: GND
Pin 5: ~14.2v DC unloaded
Pin 6: GND
Pin 7: ?
Pin 8: ?
Shield: GND
Note: the RS422 protocol has a basic bus arbitration built-in to allow both ends to communicate. The control unit sends <U>Ping</U=xx> messages, after which it opens a slot for the Tablet to communicate back to it. At least on my system xx represents a simple CRC value that can be used to validate message authenticity. I haven't seen any AES encryption in use, messages I've seen are all plaintext, maybe the AES encryption was introduced in a later revision.
Interesting, not sure what's going on there then.. how recently was your system installed? Maybe they have updated the pinout on newer models? I'll go back and check though.
I got inspired, and have plugged in my scope, and then an RS422 to serial adapter, and I'm getting XML encoded (weird) CAN messages, which I presume are the same as what's on the CAN bus exposed on some of the control box's ports. I'll get out the can analyser tomorrow and check.
Now the trick will be to reverse engineer this protocol. Here's a tiny sample:
The AES encryption might be related to the android intent messages that are sent to the AAservice. I recall they had an encrypted mode and a "signed app" mode that AAservice will respond to
I have decompiled the apk and it produced a somewhat useful (but incomplete) package of Java source files, which can be useful for reverse engineering the serial protocol. For example:
<string name="parse_block_tag_ping"><U>Ping</U=db></string>
...
private static final byte[] f2305f = "getCAN ".getBytes(Charset.defaultCharset());
private static final byte[] g = MyApp.a().getString(R.string.parse_block_tag_ping).getBytes(Charset.defaultCharset());
private static final byte[] h = MyApp.a().getString(R.string.parse_block_tag_startu).getBytes(Charset.defaultCharset());
private static final byte[] i = "<request>Unknown</request>".getBytes(Charset.defaultCharset());
You can do the same, or alternatively ping me if you'd like me to email you the source package.
I have reached out to your email address (as described in your profile) with some additional information that I've been putting together. Let me know if you didn't receive my mail.
Cheers, I am looking at this for our system but it is still working so I didn't want to mess it up, but was planning for the eventuality... I've been reverse engineering the app, so your post has cleared a few things up for me :)
The plan is to get rid of the tablet and put a Amazon echo hub or HA on a tablet that directly controls the aircon in the future
Feel free to reach out, a few people from this thread seem to be doing similar things, including looking at the protocols involved and interop requirements. It would be good to combine efforts if you're that way inclined.
As far as HA integration goes, there's already an adapter available that uses the HTTP API that the tablet exposes. This of course still requires a working tablet though.
The next step for an open solution would be to either write a replacement for the tablet API that talks directly to the control box using RS485 (which will have the benefit of allowing existing integrations to work as-is), or perhaps even ignore the original API and start from scratch with something custom built for HA integration.
The original HTTP API that the tablet exposes is relatively straightforward, but it also commits quite a few sins against HTTP, such as mutating state on GET requests (making CSRF type attacks trivial). This makes a like-for-like replacement a little less palatable in my eyes.
The other tricky thing is that the tablet code is where a lot of the state is kept and the smarts of the system are located. Zone names and config, schedules, temperature sensor pairing, ... replacing the tablet API completely like-for-like might be tricky, but doing just enough to support HA integration (maybe submitting a patch to the existing integration to support the new custom API) is probably a much easier task. There should be no need to rebuild features that HA already has such as scheduling etc.
Since it's not just a generic non-programmable serial chip I assume it's also doing something more. But it doesn't do Ethernet so I bet it's not actually PoE but like... power+serial over Cat5
I believe point #3 describes a paradigm shift from thread-based programming to a more event-based approach (which still uses threads/co-routines) rather then implying that everything will be single threaded
Yes.. having a large amount of concurrent users (>100,000) is definitely a challenge, and polling each time adds to the load as you are creating a new connection every time.
Our approach was based on horizontal scaling of commodity hardware (on Amazon EC2). We have X number of worker instances serving clients and they internally publish and subscribe using a Redis cluster. Have a look into Redis, ZeroMQ or RabbitMQ.
But definitely give our service a try in your free time or for your side projects :)
Thanks for your comment. We believe offering our users more choice is always a good thing. Moreover, while we do provide a similar service, the way we deliver and our goals are slightly different.
Pusher uses WebSockets; this is awesome and a very forward thinking technology however can be limited by older browsers and proxies not supporting the WebSocket connection. Notifyr uses EventSource (also a HTML5 spec) and XMLHttpRequest, aiming to support a majority of browsers, including mobile browsers.
Additionally, we aim to integrate with Apple and Google's push notification system in the future, allowing a universal method for sending push messages with one API for any platform, device or browser.
More choice is only a good thing when you make it abundantly clear what it is you're going different, and why someone should use you. Otherwise, you're just making it harder for people to make a decision about what tools to use. Your front page doesn't do a very good job at that right now.
The fact that the claim you made here about Pusher and legacy was so quickly disproven, makes things even worse.
