Nice job man. I may wait a few more weeks for a slow weekend (and also to see if Matt & co. offer any condolences/advice for us).
One thing I think is worth noting since I’m seeing this on Reddit too—I think people genuinely would be willing to pay you $1-$2/month to host the server and allow them to connect, which may be successful if you make it easy as possible for them to connect.
I was thinking about this a bit more. I wonder if @Matt and team would be willing to turn over the “keys to the castle” in terms of pointing the DNS records to some server you have running that way people don’t need to flash their devices? Not sure what endpoint they request the webp’s from.
I don’t think I’d want that responsibility . . . Maybe a small firmware update to allow that to be a settable option.
Awesome work Travis - I flashed a gen2 and installed the sever/Docker on a Pi 5 and it worked!
I will have a go at flashing one of my gen1 units soon.
Awesome ! Glad it’s working. It’s in pretty active development right now so I’m glad you got a working version :). I’ll be doing more responsible commits just to development from now on 
(and writing some tests even !)
This evening when going into the web UI and Tronbyt Manager, then clicking Add app, there’s no longer an extensive library of apps to choose from - just a blank template for creating your own. Have tried restarting the docker and Pi itself.
Any thoughts on what has caused this?
Can you post a screenshot ? Are you sure your not on the upload page ? I can’t think of a reason that page would be blank unless maybe the pi filesystem got corrupted maybe.
There has been quite a lot of development lately but I don’t think you would have updated the the code right ?
Here’s the screen shot when I click add app, plus one of the admin repo setting, which I guess may be the cause:
I re-ran:
docker compose -f docker-compose.dev.yaml up -d --build
and the repo entry above was cleared and the apps have come back!
So, could I simply have removed the repo entry or did I need to re run the compose command to restore the app server apps?
Thx
tronbyt-server is not the apps repo so I don’t know how that got in there. If that happens again try putting in tavdog/tronbyt-apps and clicking save and it should reinstall all the apps.
tronbyt-server is working fine now, thanks. A couple of queries:
A few apps I’ve tried adding that have Locality and Timezone settings (E.g. clock by Henry and solar elevation) do not keep appear to keep any changes after you have saved and when you go back into configure - they have reverted back to Brooklyn/NY and America/NY.
On Home Assistant using TidbytAssistant, is is possible to have tronbyt and tidbyt devices running concurrently - this would require two base urls (tidbyt’s and your local tronbyt server) being set in the add-on configuration?
The tidbytassistant author has already made some changes to allow for it to push images to tronbyt server. It should work fine in the near future.
I rebuilt my Tronbyt Docker container with the aim of hopefully fixing some quirks after much tinkering and to learn a bit more in the process. However I have a few issues that I’m not sure how to resolve:
(1) Home Assistant TidbyAssistant integration: With the apiurl set in my configuration.yaml file in HA to the tronbyt server I.e. http://{mytronbytserveripaddress} and the latest TidbyAssistant integration downloaded, I’m getting a 404 error when trying to push text to the tronbyt, “message='Attempt to decode JSON with unexpected mimetype:” The device ID and API token I believe are correct in the yaml. I have tried with just the tronbyt device active in the yaml and setting port 8000 and adding :8000 at the end of the apiurl field. When I uncomment out my other tidbyt devices, I can push text to these fine. So it’s something specific to the tronbyt server URL that I’m mistyping or the docker image is not liking. I can browse to the ip:8000 fine but I don’t know how to check using the device ID and API key.
(2) API key flashed into the device: The tronbyt API key has reverted to “CHANGEME” on my newly built version of the tronbyt server - can I paste the API string I saved from my previous device entry in the original container or do I have to re flash the tronbyt firmware again? I’m guessing the hardware itself still has that original API key? I’m wondering if somehow I have a mismatch in the API key I have been using in my yaml file to the one that is actually flashed on my device, so my next step could be to add a new trophy device in the server and re refresh the device and use this new API key to see if this resolves (1).
(3) The newly composed tronbyt server works and I can add app and it displays fine, but when I click configure to set locale etc the app screen is blank, see screen capture.
(4) Should the render time for apps such as clocks be set to 1 min not 10 to ensure they refresh in near real time?
Would welcome some further guidance. Thanks,
To manually push a webp to the tronbyt via the tronbyt api you would do use curl like this :
curl -X POST --url http://m1pro.local:8000/v0/devices/04a7985c/push --header "Authorization: TESTKEY" --header 'Content-Type: application/json' --data '{"image": "'$(base64 -i test.webp)'"}'
where TESTKEY is the actual key, test.webp is an actual webp or you can replace that whole $base64 part with the actual base64 string of the webp.
Yes you can just paste in your old api key but if the id has changed then you do need to reflash as the device id is part of the image url.
Does that white screen happen for all apps you try to configure ? I tried with aquarium and it worked for me. If all, then it’s something to do with the pixlet render part. There have been some changes to how that works. If you open up the dev tools window → network in the browser and then click configure it might show you what request is not working.
Yes set the render time to 1 minute for fastest refresh rate. I guess if we set it to zero that would be update everytime. good idea.
thanks for the good user info.
Thanks Tavis.
Useful command - I’ll do some testing with it when I have a working device.
Good to know re the API key. However, I have deleted the tronbyt device entry and created a new one, so the device ID has changed. I have the original flash file I created and I have a record of its device ID but this may be the issue if this is actually incorrect. 
What is most odd, is I cannot flash any new firmware I create to the device. It goes through the loading the file then hangs with a few LEDs lit or sometimes nothing at all on the display. I’ve tried numerous fresh firmware files, all gen2 of course. However, the odd thing is I can revert back to the original firmware file I created on the 9th Feb and the device boots up with tronbyt on the display and then comes online and responds to pings, but of course I cannot manage it from the tronbyt server as the ID has changed. So the flasher seems to only work with the original file once a tidbyt has been flashed. I can’t see a way to factory reset the device as holding the reset button does nothing on the tronbyt firmware. I’m back on that original firmware for now, so if there’s way to configure the device ID in the tronbyt server device entry then that could be a way forward. This may be a toasted device from this point on I have 2 gen1s that are still tidbyt gender.
The white screen is for any app when going into configure - all just show blank boxes. Just tried in Chrome (was using Safari) and it does the same, but scrolling down, it shows “refused to connect” - dev tools does not flag anything other than the sessions to port 5001 with a referrer session to 8000, only port 8000 is open on my Pi according to Nmap. Could port 5001 for pixlet not being open be the issue?
Thanks - good to know.
Yes ports 5001 and 5002 should be opened for the pi. Needs those for pixlet serve.
But I don’t see why flashing new firmware would succeed on some images and fail on others. Is it doing a boot loop you can see on the serial ouput of the flasher program ? just rapid repeats of werid boot messages ? There is a firmware checksum correction step that must succeed for the tronbyt to successfully boot with the modified bin file and if that isn’t succeeding then it will just boot loop after a flash. But the flashing lights usually just means that the flashing failed to even start. I can implement a feature where you can specify the id of the device apon creation so that you can use the original firmware. It’ll take me a few days though.
There is also a hack for setting the device id before you bring the container up but you have to also delete all the volumes associated with the container.
In the file db.py there is a function call init_db which has the default device information hard coded. you could edit the device id there and then when the db is initialized the default device will have the device id you have specified :
# Load the default JSON data
default_json = {
"username": "admin",
"password": generate_password_hash("password"),
"devices": {
"9abe2858": {
"id": "9abe2858",
"name": "Tronbyt 1",
"default_interval": 18,```I’ll look into the reason ports 5000 and 5001 are not open…
The re-flashing of new firmware file just loops on reboot with the following, so it sounds like a checksum failure as you suggest. Specifying a device ID would be very helpful assuming this firmware doesn’t hit the same boot loop issue. I’ll eliminate USB cable, USB hubs etc in case these are corrupting the firmware file:
[09:54:04]rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[09:54:04]configsip: 0, SPIWP:0xee
[09:54:04]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[09:54:04]mode:DIO, clock div:2
[09:54:04]load:0x3fff0018,len:4
[09:54:04]load:0x3fff001c,len:1044
[09:54:04]load:0x40078000,len:8896
[09:54:04]load:0x40080400,len:5828
[09:54:04]entry 0x400806ac
I now think the original firmware that does flash fine must have the default device ID 9abe2858.
Thanks
Yes that boot loop means that the modified firmware file is not being generated properly. send me an email [email protected] with your device id and wifi creds and I can generate you a good firmware to flash.
it’s possible the raspberypi image is not working correctly. I’ll test it tomorrow.
For those who are following this - the latest tronbyt-server image fixes the firmware issue and some other bugs. My gen2 is running well as a tronbyt with 30 odd apps, many doing API calls or displaying Home Assistant sensor entities such as the outside temp from my Tempest weather station and Netgear uplink/downlink speeds. The Raspberry Pi seems happy with the server loading. Would be great to have some of the other Tidbyt apps ported across, and features such as pinning an app (useful for when you have visitors over for dinner and you don’t want them distracted or hypnotised but the ever changing display!).
