A CH5 project is just a User Project made with the new Crestron HTML5 User Interface. It’s the new way to write projects for these tablets.
For now, there’s sadly nothing I can actually deliver - I still have a bunch of JavaScript code to figure out. The end goal, though, will be a .ch5z file that anyone can upload to their device, set a couple URLs, and have as native of a Home Assistant integration as I can reasonably deliver.
At some point I should probably start a Discord server or something for people who are interested in this… I’ll put that on the todo list eventually.
As a quick update: there’s now a GitHub repo for the ch5-ha-bridge project. This is still very much a proof of concept/work in progress, but it is at least complete enough to be worth sharing.
At the moment, it will publish various information to the MQTT topic crestron/ch5_mqtt/<MODEL>_<SERIAL>. At present, the following is implemented:
joins/:type/:join_name (R/O) will publish changes to (known) joins.
ledAccessory will show information about the LED bar.
/power (R/W) controls LEDs.
/brightness (R/W) controls the brightness, scaling RGB values accordingly.
ledAccessory/color (R/W) controls the color of the LED bar.
events/button/:buttonName shows information about each physical button.
/press (R/O) will be true if the button is held, false when released.
There’s still a lot of work to be done here, but this is at least a first step in hopefully the right direction.
Also, we’re finally getting our first look at the TSW-80 devices. Seems like we’re going to have both an 8 inch and a 10 inch version, now with USB-C. The confidentiality in the FCC database expired, so it’s in the clear now.
Congrats! This is a very big first step in this process. Thank you for the work to get this far!! If I could help, I would. I’m a horrible coder and I know very little about the ch5 platform but I will be following this project closely.
Alright, so time for the next big hurdle: CH5 apps do not support local storage or cookies to store data. I can get an iframe to partially load, but the actual Home Assistant UI will perpetually hang:
Curiously, this only seems to affect CH5 apps. General Web projects suffer no such restrictions, probably because it’d be a heck of a lot harder for any standalone app to work with that limitation.
So, right now we have a bit of a conundrum: General Web (EMS) mode supports local storage and can actually boot Home Assistant, but can’t access the full join table. CH5 apps can access the full join table, but block any sort of persistent data.
We still can connect to the Home Assistant API and set that up, so I guess custom-made dashboards and platforms would still be possible to some extent. Unfortunately, the lack of local storage also means that any credentials or configurations would need to be baked into the bundle… nowhere near as simple as an on-board config interface. Perhaps we can call in the HA Component Kit for an assist?
I’ll keep looking to see if there’s a workaround, but I’m not particularly confident in the moment. I suspect I can at least get Home Assistant proper running via a polyfill of LocalStorage, but there’ll still be other problems that need to be resolved. (Edit: yes, a polyfill works, and a bug report was opened for this).
Edit 2: For some reason, I apparently have access to IndexedDB, at least on a 1060. So, there’s at least some capability for persistent storage, but I doubt the Home Assistant project would be willing to add that for something so niche. Perhaps some extra code somewhere post-bootloader?
I had thought about using EMS with some JavaScript called via browser_mod to register the buttons, light bar, etc., but haven’t gotten around to testing yet…
I was looking into that, but I also wanted more control over arbitrary joins. So I decided to shoot myself in the foot!
For those following along, the polyfill I pushed to the repo works, but does require some nasty hacks beyond itself. It’s worth nothing that while the polyfill is fast-ish, it’s not fast enough. To resolve this, I created a new coldboot.html file that takes a redirect_to query param. This coldboot file loads the polyfill early, allows the IndexedDB to initialize and copy everything it needs into the session store, and then finally redirects to the specified param.
There are most likely better ways to solve this once I get around to thinking how the bootloader will work, but for now it does allow some session persistence at the HA level and permits auto-login. Of course, if someone were fine reconfiguring everything after every boot (or you have a way to already tell HA what you want to do), then perhaps this hack isn’t needed.
I still ultimately want to keep this code somewhat modular, since I suspect some people will want to reuse their Lovelace dashboards while some people would rather build nice bespoke dashboards with React elements.
We’ll see where this goes, but we’re still making slow progress despite weird and unexpected walls.
Potentially you’d want something similar to how these work natively where you register the device with a server, in this case Home Assistant. Once registered and every time the device reboot and contacts Home Assistant, it auto logs in to the assigned Home Assistant user and shows a dashboard.
Once registered and every time the device reboot and contacts Home Assistant, it auto logs in to the assigned Home Assistant user and shows a dashboard.
HA itself has a hard dep on needing (working) LocalStorage. See Frontend issue 25837 for the actual “bug” here.
It’d be awesome if there was a feature like an “embedded dashboard” in HA, where a full dashboard context could just be dropped in an iframe with no auth or any other provisions save a magic link. Would be absolutely perfect for this use case. Likewise, if one were to allow auth via IP address, that’d also be fine with a (far simpler) polyfill - just bind localStorage to sessionStorage:
If I’m willing to require everyone build their own .ch5z file, yeah, I wouldn’t need any form of localized storage at all. Ideally, though, you’d be able to just install a .ch5z, add a frontend add-on through HACS, set some variables on your tablet, and be good to go. I consider this a stretch goal, but it’d be a pretty neat one and would make saving these tablets from e-waste very easy.
New HA user here and new to the forum. I have my HA system running on the Green platform and have managed to get things running pretty well via my phone and computer. I was looking into adding a wall mounted display and the Crestron seemed to be a good fit so I went ahead and ordered a TSW- 1052 off ebay. I should have looked more carefully in this thread about the ability to run a 1052 with the EMS function. It now seems this may not be possible so ordered at TSW 1060 and will chalk the purchase of the 1052 up to not doing enough due diligence. Has anyone found a way to use HA on the 1052? If not it wasn’t a painful and expensive lesson, but it would be nice to use it for something if there is a way to run HA on it.
Meanwhile in status updates nobody asked for: have some videos! Crestron in Node Red is also a thing (and yes, plain-old automation templates also work).
Interestingly, as part of doing the power button behavior, I did realize that the User Project mode completely gets rid of that boot delay. The screen really does just turn off, and the app keeps running in the background.
Currently next in the todo list:
Add some kind of persistent data store, so that I can stop hardcoding things in a .env file
Add MQTT autodiscovery
Add basic UI
Setup screen on holding the HOME button for 5 seconds.
Figure out some better way to do bootloader shenanigans.
I will note (once again) that these devices very much do have some limitations. Modern versions of CardMod (for whatever reason) cause things to get very slow even when no custom CSS is loaded, and the 1060 is perpetually stuck at Chrome 95. But it does work!
This is very cool! I’d love to have instant on/off on my 770 panel. Curious if it’s possible to use the same project on mine? I’ve also got a 760 I’ve been wanting to play with if you’d be willing to share the project.
For anyone else looking at this thread, I made a video detailing how to use Node Red to control the Crestron panels with Home Assistant. Happy to remove this message if mods here don’t like YouTube links.
It should work on a xx70, but I haven’t tested. I linked the project above, but have another one. You will need to build it yourself, but it isn’t too bad.
Gonna put out my call for help again, if it’s alright. I just finished making a bunch of issues on the bridge project to kind of describe my roadmap/project vision, and would love some feedback or commentary on it to see what’d be most useful for people.
Likewise, if anyone wants to volunteer some time to work with evil TypeScript code, by all means, please feel free to jump in! The bridge project is going to be a pretty long effort, so I very much expect that it’s too much for one person.
Thanks for taking the time to create this - I’m liking the possibilities it creates!
I may have built it wrong, but I got it deployed onto my 1070, and I only only see an Android error page with:
Webpage not available
The webpage at https://<MY_HA_URL>:8123 could not be loaded because
net: ERR_BLOCKED_BY_RESPONSE
So maybe it doesn’t work on an xx70?
I copied .env.template to .env and put in my own HA URLs. When I built it, it did complain about one thing:
Vite is running in mode: development
vite v6.3.5 building for development...
<script src="./cr-com-lib.js"> in "/index.html" can't be bundled without type="module" attribute
✓ 58 modules transformed.
…but otherwise the build was uneventful. Deploying was simply a case of using npm to install @crestron/ch5-utilities-cli and @crestron/ch5-shell-utilities-cli, then running up ch5-cli as shown in the package.json.
I’m thinking one of four possibilities:
Built incorrectly
Used wrong version of node - 22 LTS
I use https on my HA instance (but it has a valid ZeroSSL cert)
It doesn’t like the login page? (hence the ‘blocked by response’)
Not compatible with 1070
***EDIT: Something is working though, as I see the creston/ch5_mqtt/TSW-1070_<SERIAL_NO> in MQTT, and it is updating…
The Vite warning is just a warning due to how the project is built. I’m lazy and don’t want to deal with making that better yet.
HTTPS is going to be annoying, since unless your Home Assistant has a publicly-trusted SSL certificate in the TSW’s store, you will need to load the relevant root/intermediate certificates:
For development purposes, I’ve really just stuck with using plain-old HTTP for now. Give that a shot, perhaps?
You will also need to add the following to your global HA configuration.yaml:
http:
use_x_frame_options: false
I’ll add all this to the readme. (edit: the readme has been updated with everything I remember doing to hack this onto the panel. Let me know if you still have issues.)
Adding use_x_frame_options makes HA logon screen appear, which would suggest that https must be working otherwise I can’t see how it could even talk to the server (https + EWS works, so my cert can’t be too bad).
Once logged in though, it just stops at that point - the screen changes to the usual HA loading screen after login and then it sits there.
I’ll have a go at disabling https, but I’m not sure it will help considering it’s using https to display the login page…
Okay, now I get a black screen with a white, single pixel high bar across the top of the screen…
When I visit the coldboot URL I set in VITE_HA_DASHBOARD_URL in Firefox, I see the “Crestron Tablet Cold Boot” banner - but the dev tools show an error running the Javascript “TypeError: can’t access property “onDataLoadComplete”, window.localStorage.__storage is undefined”
Unfortunately, I’m a C/C++ dev and have never touched TypeScript, so I don’t really have a ‘favourite TypeScript compiler’ as per the docs - I might have compiled it incorrectly:
I have a TSW-1060 & TSW-760 as well, so I’ll upload the project to those tomorrow. If it fails to work as too, I’ll turn https off to give it a go… I’ve avoided doing this so far because I can’t remember if there were any side effects/addons not working…
Ok, I ran it on my 1060 and it failed as well… but the difference between the failure on the 1070 and 1060 is that I can just about see the error being displayed on the 1060.
So I’m a bit of an idiot. I had put “redirect=<my_ha_url>” rather than “redirect_to=<my_ha_url>”
I can confirm that both my 1060 and 1070 can connect to HA (via https too) using your app, with the polyfill mod! Great stuff!
[EDIT: subsequently found the dark screen on failure was due to my auto-brightness settings being too extreme]
- I might have compiled it incorrectly: