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 think I have a clue. I managed to reliably reproduce the issue on a Lenovo P15s notebook running windoze 10. It will reliably disconnect if I run iw ra0 scan in a loop on OpenWrt 23. So I ran Wireshark to check for lost packets, acks etc, nothing notable to report. However I did notice the Wifi signal strength kept dropping and then the SSID disappears. If I set the saved network to autoconnect, it reconnects fine. But as the loop runs it disconnects again and then reconnects etc. I put my iPhone and Android 11 devices next to the P15s at the same so they are the same distance from the Omage2p and neither of them disconnect when the windoze device disconnects.

This Lenovo P15s can dual boot either windoze 10 or Ubuntu 24.10, so this time I booted into Ubuntu and ran the same test, it doesn't disconnect. So the problem is isolated to windoze.

I ran LinSSID on Ubuntu and it does not detect any notable drop in signal strength, so I rebooted in windoze and ran Acrylic WiFi Analyser, it shows a short-lived drop in signal strength when I'm running iw ra0 scan in a loop.

My working hypothesis is that windoze is aggressively monitoring connectivity and the faster the machine the more likely it is to disconnect, but slower devices like iphones, android phones and old Surface devices are simply not noticing the short lived signal drop.

OpenWrt 22 uses iw v5.16 OpenWrt 23 uses iw v5.19, so I wondered if the newer iw is doing something different. Looking at the code the changes are minimal, so I installed iw v5.16 on OpenWrt 23 but the issue persists.

Both 22 and 23 use the same mt76 firmware release, so I'm looking at the driver code for some hints.

@eng_Ahmed I think everyone needs to use the approach that best aligns with their current experience and expertise. My approach would be to build the package from source and then install it on the devices. I think it's a slower start than simply installing the packages but by building from source to start with, you already have a leg up on task 3, you also can evaluate what each configuration change you make in stage 2 actually does at source code level. So by the time you are ready for stage 3 you already have an understanding of the code.

@ElGoose39 Take a look at the 23.05 documentation that has a detailed explanation on how to create your own repository. You could then remove the old version of python and install your own version. This documentation is relevant to the earlier Onion firmware 18.06 as well.

@eng_Ahmed ipip (ip tunnelling) needs the kmod which needs to be build for the kernel you are using. But since you are using oonf-olsrd2 package it doesn't have that dependency.

@shoresup you can isolate the file system as a performance bottleneck by running a test using dd. I create one file name myread containing:

#!/bin/sh

dd if=/dev/zero of=myfile bs=8k count=10000
sync

and another named mywrite containing:

#!/bin/sh

dd of=/dev/zero if=myfile bs=8k count=10000
sync

Now run these commands to see their timings:

time -v sh myread
time -v sh mywrite

This will give you the file system timings for reading and writing 10000 blocks to and fro the file system

There are other tools but I like dd because it's a really basic test

@DocHardinger Can you set option disassoc_low_ack '0' on your AP and see if it makes any difference. I need it on my sta when connecting to one of Unifi APs.

@DocHardinger said in 23.05.3 iwinfo scan disconnects AP:

with old mt76 driver and it disconnects it cant be the driver, right?

Well. The Mediatek driver is broken up so that the various Mediatek hardware drivers use various shared code, and leverage the kernel and other kmods so that can also be a factor, but I built on the 6.6 kernel whereas the Onion build uses 5.15.

I have more things to test, this will also impact my own devices so I am keen to get to the bottom of the issue before it bites me in the ass.

Tonight I'll add some logging to the kmod and see if it gives some hints as to where to look next. My main issue is being able to reliably cause the dropout. My guess is it is lost packets perhaps due to power issues and or the windows driver's tolerance of these. The hardware and/or drivers on my Windows notebook may be more tolerant than yours, so I tried it on an old Mickey$oft Surface device, it never dropped out and that's a pretty crappy piece of hardware.

@DocHardinger That was OpenWrt 23.05 with the OpenWrt 22 MT76 driver code merged in. I tested on my Windows 11 machine, ran 6 or 7 scans and it never disconnected. May I suggest, if you have not already, power your Omega2 using a USB power adapter. Wifi scanning typically shows a spike in current, so I wonder if that's the issue.

@shoresup Have you used iperf to measure your actual performance? What rate are achieving?

If you are not in the US change your country option to match your actual country. I'm in Oz and if I leave my Omega2+ set to US, performance seems to fluctuate. The cause is the difference in wifi frequencies between the AP and the Omega2+, since hardware available here in Oz adheres to the Aussie regulations which are different to the US regulations.

If you run iperf and record the results then update your device to openwrt 23 Beta release available here you can easily do a performance comparison.

@eng_Ahmed You also need to install ipip package which is in base so it should be available opkg without any changes to distfeeds