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.

@DocHardinger I'm currently travelling so haven't completed my testing since I don't carry a Windoze machine with me. However what I found thus far is that if I slow down iwinfo by ~200ms each probe, the windows machine does not disconnect.

The question I want to answer, is whether this tiny delay simply reduces the load on the Omega2p so it can respond to the network requests in a more timely manner. If this is the case, then my earlier hypothesis that windoze is simply less tolerant of response time variations than lesser systems, would appear to be true.

But I am not yet prepared to make that conclusion until I have done more testing, but if this were the case then we just create a patch to add this functionality.

@eng_Ahmed So this is where you need to do bit of hacking. Since both luci and OnionOS want to use the same directory, we need to backup the /www directory to some place else:

cd /
mv www www2

Which moves the current www directory and it's content to a new directory named www2.

Now force opkg to install luci, ignoring the perceived conflict:

opkg --force <luci package name>

Now you'll have both packages installed, you just need to configure lighttpd to find luci the www directory and OnionOS in the www2 directory.

One thing buzzing around in the back of my head is that I seem to recall (but may be wrong) there was some hardcoded /www references in the OnionOS stuff, so you may need to do the reverse and put OnionOS in /www and Luci in /www2. Just juggle them like this:

cd /
mv www www3
mv www2 www
mv www3 www2

Those directory names are abitrary, you could call them something like www_luci and www_onion you just have to tell lighttpd where to find them.

@eng_Ahmed Take a look in /etc/opkg/distfeeds.conf, I don't have one available to me right now but you can uncomment lines 2 and 5 and then run opkg update, then try installing again. Otherwise post your distfeeds.conf here so I can see. My internet is like a yoyo right now (thanks to the earthquake on Thursday) but I login when I can.

@Alberto-Brosich Try this configuration of network and wireless and tell me how you go ,just change only the client parameters (nothing secret in mine):

/etc/config/network:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'
        option disabled '0'

config globals 'globals'
        option ula_prefix 'fd80:3b06:c6c7::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'wlan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.3.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option disabled '0'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '0'

config interface 'wwan'
        option proto 'dhcp'
        option device 'apcli0'
        option disabled '0'

config  interface 'lan'
        option device 'eth0'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.4.1'

/etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/10300000.wmac'
        option channel '11'
        option band '2g'
        option htmode 'HT20'
        option disabled '0'
        option country 'ID'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'wlan'
        option mode 'ap'
        option ssid 'dash'
        option encryption 'psk2'
        option key 'gnkdsjhfksfksgf;isyuf'
        option hidden '0'
        option disabled '1'

config wifi-iface 'client'
        option device 'radio0'
        option network 'wwan'
        option mode 'sta'
        option ssid 'MarriottBonvoy'
        option key ''
        option encryption 'none'
        option ifname 'apcli0'
        option disabled '0'
        option disassoc_low_ack '0'

@Alberto-Brosich your ssid key in your post is only 5 characters in both the sta and ap, perhaps you masked them out for the post, but if not then this will cause the issue ifup issue. Since you have selected psk2 encryption, your keys need to be between 8 and 63 characters.

@eng_Ahmed OnionOS OOTB uses Lighttpd as does Luci, so both can run on a bare bones web server. The main issue is how they can both coexist on the same server and how your browser request gets directed to the correct site.

I should note that I haven't tried this specific configuration, but I do use a multisite configuration on my devices, Lighttpd is amazingly functional for such a small footprint and includes conditional processing of requests.

Take a look at the configuration tutorial, you can see it is possible to create virtual hosts using the conditional url parsing.

@DocHardinger Here they are: OpenWrt Archive

@DocHardinger Oops yes you are correct. Let me see if any of the other slow mirrors I found previously have it. Otherwise we can always build it.

@Alberto-Brosich can you post the output of the command uci show network

@DocHardinger These are some of the reasons I build my own firmware

Their log indicates some issue with missing rust compiler.

Report the issue on openwrt forum, some of the devs haunt that place so you might get noticed, it's broken on 24.10 as well so it'll get some attention.

Here is a link to a mirror of the openwrt repo that seems to sync every few days, I just checked and the ipks you need are still there so you can grab them ASAP.