I designed this case so I could wall mount my Omega Dash. The case is in two parts that clip together using snaps. I designed this using the Dash Beta device and the LCD moved around a bit so some adjustment to the LCD recess may be required, I'll update it once I receive my production devices.

Here is a photo of the rough 3D printed version, it needs finishing and I am a terrible photographer.

This is printed on a FlashForge Guider2S using PLA filament, the extruder is set to 220 degrees, the bed is heated to 20 degrees and I use a glue stick for adhesion. I print the top plate face down so there is no need for supports, no brim and no raft.

STL files are here: https://github.com/crispyoz/Omega-Dash-Casing.git

@DumTux The process is:

git clone https://github.com/OnionIoT/omega2-bootloader/
cd omega2-bootloader
./setup_env.sh
chmod +x build.sh
./build.sh

This produces 2 files:

uboot-omega2-<date>.bin
uboot-omega2p-<date>.bin

The latter is the Omega2+ uboot

I've posted the details of my wall mount in Projects.

https://community.onion.io/topic/4173/3d-printed-wall-mount-case-for-omega-dash

I don't work for Onion but if I did, I'd have as many complaints about the cost as I would have about why there was only features. In the end you just have to make a decision as to what is the best combination of features and price, or you will never release anything. The market then responds and you adjust your design or you offer new models.

As a Beta tester, memory was not my issue, LittleVGL is not perfect but I looked at so many other potential GUI candidates for my specific requirements and in the end I came to the same conclusion as Lazar and Zheng. LittleVGL is a great fit for the Omega2 and if you need more, you can always build a custom board or an expansion board. The underlying technology is solid.

I was lucky enough to join the Beta for this product. It's a great device, the GUI LittleVGL takes a little effort to understand but it's pretty full featured and works well. It's got an Omega2S+ under the hood so if you're familiar with Omega2 it's easy to get started.

Love it!

@supczinskib Intelligent watering systems are not a new idea, but any exiting idea can always be improved so I am interested to see what you come up with.

I currently have a home automation system installed in my apartment and a very large garden (image attached ) which I integrated with my home automation system so I've been tweaking this for about 7 years now. I do see a potential flaw in your "Automatic" system. Watering plants is more than just weather, it is about soil moisture and soil moisture is impacted by numerous factors, including the type of soil, ground coverage and obstructions. For a very basic garden maybe this idea would work, but a garden of any complexity will require reading soil moisture otherwise you'll end up over watering or under watering. Different plants require different moisture levels to survive so I ended up using moisture sensors in order to allow my system be able to understand the moisture content of the various areas of the garden and any specific plants that need special attention.

@MK When I switched from OpenWrt 18 to 22 is was quite smooth, but it depends on what functionality you are using. Initially the network setup was a pain, then changing MUX setting of a couple of pins was an issue. Then an issue with ledchain, then an issue requiring conversion of sqlite3 db. Mostly these were easily resolved so now I run 23 on my devices without issue. Also initially I started experimenting with OWRT 19, jumped to 22 then went into production on 23.

@MK thanks, yes I saw your time clock gizmo, nice piece of kit. Congratulations.

@Lazar-Demin The reason why I think a PoE version would be useful is as @MK mentioned, getting power to devices is often a pain, I think especially in a development of IoT devices I want to test devices in various locations and honestly I prefer to cable my stuff for reliability as WiFi is not often reliable in some locations. Especially when I'm fixing things to walls or up in the ceiling of a building where cables, metal and fluorescent lights may be found. Getting an ethernet cable to some of these locations can be a challenge, but getting power there as well can get really complicated and expensive.

I also think a solid reference implementation for use with Omega2S+ would be a bonus, or even better with the Omega3S+

While perusing the source today I noticed there have some recent additions to the uboot code referencing Omega3.

"Onion Omega3 IoT computer. Has a MT7688 SoC with 128 MiB of DDR2
RAM, 2 MiB of SPI-NOR and 256 MiB of SPI-NAND flash."

Is it so?? @Lazar-Demin

@baby-Onioneer Since the Omega2 devices utilise OpenWrt and u-boot, the question really is for the OpenWrt team. I watch the OpenWrt developer lists and there has been a lot of discussion on this topic over the years and they seem to always come back to the same point. If you need to rescue a device you need to be able to access the console for safe mode or reflashing using the u-boot tools. Once you're in safe mode it is possible to mount the overlay file system. Locking that down would hinder recovery.

Even if you locked down the console, anyone who gains physical access doesn't even need the console, you can simply remove the cover and access the flash directly. So now you have to look at an encrypted file system, but that presents range of issues.

The approach I take is to not keep any sensitive data on the device for any period of time. I also use some logic to determine if the device has been tampered with, or too many failed logins. If any of these checks fail then any sensitive data or configurations will be purged. I have an override mechanism for this process. None of this prevents a determined user from access the flash directly and perhaps getting some sensitive stuff, but in my experience hackers try a few other things before resorting to wiring up the flash and by that time anything sensitive has been purged.

Thanks @Lazar-Demin saved me some work.

@defa85 I don't use VS code but you can debug python code using gdb and you can run a gdb server on Omega2. I mainly develop in C/C++ and debug using gdb remotely.

Thanks @Lazar-Demin and @luz . I'll look at the swd-spi overlay to see if it works for me, I need it on owrt 24.10 so hopefully it works there.

I'm not quite there with wrapper(s) yet, I agree they are great for standardisation but owrt 24.10 stable is already released and since rc5 performs well so I'm trying to keep more current.

@Lazar-Demin It's clear there were no coding standards, when I first looked at it I was a bit agast, but it's old and open source projects have come a long way since those days, try submitting that to the Apache project.

@Lazar-Demin a lot of the issues I'm seeing are caused because of the build tools version gcc 3.4.2 (released 2004), which is 9 major release behind the current 12/13 (I'm using OWRT 23). The issue @luz posted is not so unexpected due to the many changes related to how extern and inline has been implemented/standardised in the last 20 years.

As time permits I'm working though some of the these issues, but keep wondering if as you mentioned it would be better to spend time moving to a modern u-boot. I wonder if we could move to the modern u-boot but patch it to reduce size, or is it better to wait for the Omega3

@luz take a look at my fork of your fork. The issue seems to be caused by the use of extern inline in io.h and bitops.h if you change them to static inline it fixes the assembler issue.

Once that's sorted there as some other stuff to fix but I haven't had time to look at this yet.

Does anyone know why kmod-spi-gpio-custom was discontinued? I can't find any details in the sources but I have a recollection it related to a kernel change. I need full duplex spi and I'm better at software than hardware so I'm thinking about whether it's worth trying to revive it.

@luz can you give me the steps you followed and on what OpenWrt release. I can see if I can find the issue, maybe two heads are better than one.

@defa85 My first step was to divide the boot time into two sections. 1) System is up. 2) Network is functional.

If you start with section 1, issue the command service network disable and reboot (make sure you have a serial/usb connection). The system will start without loading the network, I expect this will be around 30 seconds.

Depending on what services and kernel modules you load, you may be able to tweak this a bit by disabling a service and loading it after your app, or removing kernel modules you don't need. We're talking a second or less for most of this standard stuff.

Network connection accounts for roughly 50% of the entire boot process so if you can optimise this you will notice an impact. An ethernet connection is faster and while you may think a static IP is faster, that is not necessarily the case on all routers. Disable ipv6, configure a specific channel if you are using wifi.

dmesg will give you the timings, but for more detail you can enable more detailed debugging during boot up by watching for this prompt:

Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level

press 4 and enter, then once boot is complete use the dmesg command to see the details and timing.

@luz An interesting question I asked myself when dealing with Omega2Pro flappy GPIO44 issue. I found I could modify the makefile to point to my standard buildroot, however I needed to install gcc-multilib and then it worked fine. I didn't investigate why, perhaps @Lazar-Demin knows.