I'm trying!
Feedback coming...
1 Like
Thanks, best reply to this topic -
There are lots of comments in the functions, but I haven't documented yet as I keep changing things at the moment!
I'm TRYING to find time to do this - honest I am!
Just back from hols in Finland though so washing and photo sorting come first! Then back to work tomorrow. I do want to try though. I've got the other thread open to remind me.
2 Likes
Thanks @jbudd managed to get it working, but had some issues with his screen. (his is not the same spec)
I think these were likely due to hardware limitations of his MCU, so will be useful to see how you get on.
If you let me know when you want to give it a try, I will upload the latest version before hand.
Finally found some time to actually use my CYD.
Kind of got it working after realising that Windows 11 didn't want to give up its Bluetooth use of my COM ports! (reboot needed to get them back).
However, while I've uploaded the nightly OpenHASP with the recommended driver:
While the display works fine, the touch screen does not. Anyone have any ideas? Touch screen was working with the original pre-loaded firmware.
The example panel layouts are working but without touch.
Never mind, spotted the need to calibrate the display buried in an issue. Works after running calibration, I just need to work out how to store the calibration now. I thought that pressing the reset button would do it but it hasn't.
OK, figured it out - I issued an MQTT command: hasp/cyd001/command/restart with an empty payload.
1 Like
Can you share the info page, Interested to see the specs of that screen. In particular the memory it has.
openHASP
Version 0.7.0-rc10 fb2bebf
Build DateTime Feb 2 2024 15:42:46 UTC
Environment esp32-2432s028r_4MB
Uptime 10m 4s
Idle long
Active Page 1
Device Memory
Free Heap 56.27 KiB
Free Block 51.98 KiB
Fragmentation 7%
LVGL Memory
Total 48.00 KiB
Free 37.52 KiB
Fragmentation 3%
Module
Model ESP32-D0WD-V3 rev3
Frequency 240MHz
Core Version 4.4.6
Reset Reason CPU0: SW_CPU_RESET / CPU1: SW_CPU_RESET
Flash Size 4.00 MiB
Program Size Used 1.65 MiB
Program Size Free 1.68 MiB
Filesystem Size 560.00 KiB
Filesystem Used 16.00 KiB
Filesystem Free 544.00 KiB
It looks like that is not the latest firmware RC12 OTA can be downloaded https://nightly.openhasp.com/firmware/esp32-2432s028r_ota_v0.7.0-rc12_c27c8b6.bin
Use the gui to flash OTA firmware
So it seems this doesn't have any PSRAM, I think that may be an issue with my flow, as I use scaling to create new font sizes, which requires more memory.
I wonder if I can limit it to use the built in fixed sizes 
It WAS the latest - presumably - since I used the nightly web installer to install it earlier today. 
Yes, it really is a CYD.
Well, glad I found that out now and not having done several hours of trying 
That would be good.
To be honest, I'm still in 2 minds about OpenHASP. I do so wish that the OpenHASP display tooling had been applied to ESPHome. Would have made everything as perfect as it could be.
Trying to add any sensors or controls other than the most simplistic to OpenHASP seems doomed to failure unless you do a custom build with loads of C++. This is the amazing power of ESPHome, its ease of including pre-written sensor/controller configurations with simply configuration but still being allowed to dip into C++ where really needed.
But ESPHome's bitmap display controller is just a bit too simplistic without some of the higher level objects that OpenHASP has.
Sadly, my C++ skills are nowhere near enough (nor to I have the time) to do something for ESPHome beyond the simple - mostly text - C++ macro's I've already written for a previous project.
There is a "framework" to allow for custom code, it's not too hard to add sensors etc. Although my experiments with temp sensors suggest these are best separate from the devices due to heating effects.
Inputs and output can be used as is so something like an LED or PIR etc are easy to attach.
Alternatively there is a version of Tasmota which has openhasp built in HASPmota - Tasmota
however - Currently PSRAM is strongly recommended to run HASPmota if you want to use images and external fonts. Boards without PSRAM can do basic HASPmota.
1 Like
I'll keep digging.
That is always true for temperature and humidity sensors on any platform. They are best kept on the end of a lead.
I'll have a look, I don't need lots of fonts or images.
If you want to push the boat out these are really nice - https://vi.aliexpress.com/item/1005006302276974.html
1 Like
Amen to that. Something that should be common sense, but caught me out when I started using these sensors.
1 Like
Continuing my slow experimentation with the CYD and OpenHASP.
Switched to landscape rather than portrait. Have gone through your OpenHASP flow in detail to pull it apart to understand it.
In doing so, completely sidetracked myself (as usual!) into getting the new Met Office API working and reworking your example weather part of the flow. Now separated out the weather api calls from any device updates since you only get a max 360 calls per day on the free api license and since we are using hourly data with a model that is only updated hourly, there is no point in calling the api more often than once an hour.
I've done a little flow that Saves the 48 hours of data to a flow variable but first does some data improvement - namely adding your icons and the corresponding weather name.
At the same time, I convert the data and output to MQTT as:
I've reused a small function that I commonly use that converts a JS object into individual messages, each with an appropriate nested topic.
You might also see that I've added the barometerChange property that says whether the barometer is rising or falling (yes, I need to change the output!) which might be useful.
Now I need to get back to doing some page layouts.
I don't think I'll be using your flows directly as they are more complex than I really need. But I might come up with a flow to make layout calculations easier based on some of your calcs.
I'll also need to have a flow that auto-rotates through the pages - I'd much rather do this locally on the device but the only way I can think of so far would be mis-use the idle_short event.
I also REALLY wish you could subscribe to an MQTT topic on the device because then I could use it as a backup alert in case a service goes down or Node-RED plays up.
Thanks for taking a look 
The flow started life as me trying to make some tools to help with layouts as that's the irritating bit, working out button sizes etc. especially if you then decide to change something afterwards.
The calculations are done via functions so could be called without using the rest of the flow, as that grew up around those functions to carry out basic management of the screens.
Its actually not that complex as I tried to keep it fairly modular, and make the popup widgets etc optional via the theme JSON.
If you set the file path then it writes out the complete JSONL content, which you can inspect and use independently of the flow, by copying it directly on to the device.
Does it actually work with your screen (without PSRAM) I would like to understand what I could change to allow this if not. I the only thing I can think might be an issue is the font sizes.
Can you describe what content you need to rotate through, as presumably if NR was down the content would be stale ?
If you could explain a bit more there might be a way to do this using the built in triggers for wi-fi and MQTT ?
Yes, I saw that thanks, it really helped.
I'm not sure I'm afraid since I didn't need most of it, I haven't actually run it. I'm slowly exploring what I want on-screen.
Shouldn't be stale since it is really like a single-page app in that all pages are always there so they will have the last info. I'll be sending some stuff on startup. Like the time and current weather. I'll probably eventually have a dedicated weather page. Possibly a public transport page (next buses into town). Lighting, heating. Maybe a few others.
So I might want a typical slide-show type display that simply rotates through different pages. Or, I might have it like my current M5 Basic display which turns on every other minute or two - showing some core data - then turning its display off again.
With ESPHome, I can subscribe direct to a topic from the device and show the output direct. So no Node-RED needed. So current lights, services on/off-line. Even the weather (since I'm sending the weather data direct to MQTT anyway). Since OpenHASP already has MQTT, it shouldn't really take much to have direct subscriptions.
I can also show the time directly without having to keep sending data to the device - it has a time server connection so it must already have the date and time internally. Sending the time from Node-RED (or HA or whatever) doesn't really make much sense.
BTW, changing the backlight seems very unreliable. I'm having to send the command twice, sending once rarely works. Might be the device though, not sure.
Well that's exactly what I designed it to do
Worth noting that "buttons" don't have to be buttons they could just as easily be Text or Values and colours / Icons could change to indicate service states etc.
There are already a few none button items in the Theme I created for labels, multibutton matrix and sliders. I'm sure you could get creative with the layouts, as that was my intention.
Time and current weather are already displayed in the header by default. A full weather page is already on my do list, triggered by pressing on the current weather icon.
The time/date is local to the device. If you look in the page Zero / Widgets function line 46 you can see how this is done and what formatting is possible.
There are a few discussions around this subject on github, might be worth offering your thoughts there.
This would be easy to implement as a dedicated page, a popup page or even as a Messagebox - openHASP
You are right that if you didn't want this to be controlled by NR then an idle.cmd script could be used to move to next page and reset the idle timer.
That wasn't an issue, I can easily send it from Node-RED. I am rather questioning WHY I need to send it from outside since the device already knows what the date and time is - I just can't use that information which is frustrating.
Weather is different since I wouldn't expect to be able to do the processing required on-device and I need it in Node-RED anyway. I send the data on start-up and update it hourly when my weather update runs.
Not had any time to look yet but I'm sure I will.
Here's where I'm up to. Not processing any inputs from the CYD yet but I'm now caching everything so that offline devices can be given current outputs as soon as they come online.
Nice thing is that all commands are recorded so if you issue a command from the device itself, it is still recorded and can be replayed if/when the device restarts. Direct updates are also recorded to cache so that even offline devices will get the latest outputs when they come online.
At the moment, I'm pushing out the time (as a broadcast in case I add other devices), the current room temperature and the current local weather forecast. The forecast is updated in a separate weather flow every hour between 5am and midnight.
1 Like
