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.

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.

@SpiderKenny in your user home directory there is a hidden directory ".ssh" , inside that directory is a file named "config". If these do not exist then you can create them. Inside the config file add an entry for each host you need to access, like this:

Host 192.168.1.175
HostKeyAlgorithms +ssh-rsa

Host 192.168.1.176
HostKeyAlgorithms +ssh-rsa

I created a FAQ for this some time ago:

https://community.onion.io/topic/4825/ubuntu-22-ssh-error

@huntc @Lazar-Demin pointed to the relevant description of the underlying issue (mismatched address modes) the issue is in the NOR flash not the Omega2, Onion have just activated the workaround via the DTS. Basically the CPU is in 4 bit mode while the NOR may not have reset properly and therefore remains in 3 bit mode --->>> CONFUSION!

I recall a lot of discussion of this issue on the SUSE dev list a few years ago, if you want to know more perhaps check the mail archive on suse.org.

Bu the short answer is there is nothing you can fix here.

Just the inclusion of the ETH port will save new players a load of headaches when they invariable screw up the firmware I also like that users can start off with the Omega2+ and as they progress and need access to greater functionality the Omega2S+ version exposes the full set of UART, GPIO and PWM.

I anxiously await the version that included PoE

https://www.crowdsupply.com/onion/omega2-eval-boards

@mauriziomeucci While I have no idea of the decision making process, perhaps some clarity can be found in the heading of the release announcement: "Major Beta Firmware Update: OpenWRT 23.05 ......"

The term "Beta" indicating that it is a test release inviting feedback, which would include which packages users may prefer to be included. Personally I don't include avahi in my custom builds.

Added a FAQ

While OpenWrt is a single user system, you can create additional users so you don't have to disclose the root user password. You can add the user by editing /etc/passwd and /etc/shadow or you can install the useradd package:

opkg install shadow-useradd

Now add a new user named "admin", but we don't want them to have shell access:

useradd admin -d /var -M -s /bin/false -p mytemporarypassword

The password is added in cleartext so you need to change it using the command:

passwd admin

Follow the prompts to set your password then you can confirm the new user has been added as required:

cat /etc/passwd
cat /etc/shadow

Since OnionOS uses ubus via rpc we need to add the user to the rpc user list. The configuration file is /etc/config/rcpd, but you can use uci commands to add the user:

uci add rpcd login
uci set rpcd.@login[-1].username='admin'
uci set rpcd.@login[-1].password='$p$admin'
uci add_list rpcd.@login[-1].read='*'
uci add_list rpcd.@login[-1].write='*'
uci commit rpcd

The username must match the username we just created and the structure of the password field causes the rpc daemon to use the system password we just created.

The "read" and "write" fields is set to an asterisk indicating that the user will have unrestricted access, the same as the root user.

You can confirm the new user had been added using a uci command:

uci show rpcd

rpcd.@login[0]=login
rpcd.@login[0].username='root'
rpcd.@login[0].password='$p$root'
rpcd.@login[0].read='*'
rpcd.@login[0].write='*'
rpcd.@login[1]=login
rpcd.@login[1].username='admin'
rpcd.@login[1].password='$p$admin'
rpcd.@login[1].read='*'
rpcd.@login[1].write='*'

Now restart the rpc daemon:

service rpcd restart

You can now login to OnionOS with the same functionality as the root user has, but the user has no console access.

@Lazar-Demin I'll put something together as a FAQ. Might take a few days to have the time.

@MK OnionOS / OpenWrt is a single user system, you can install a package to permit creation of users ad groups. So then it comes down to the permissions you create on whatever package you want to use. I haven't used the OnionOS stuff for a few years but as I recall it uses the the ubus acls ( @Lazar-Demin might correct me ). I use it with mod-ubus, here are my steps to create a user named admin:

# Setting up for mod-ubus (php configuration)
cd /usr/share/rpcd/acl.d/
vi adminuser.json

{
        "adminuser": {
                "description": "Administrative user access role",
                "read": {
                        "ubus": {
                                "session": [
                                        "access",
                                        "login"
                                ]
                        },
                        "uci": {
                                        "system": ["timezone", "zonename"],
					"wireless":["*"]
			
			}
                },
                "write": {
                        "ubus": {
                                "*": [ "*" ]
                        },
                        "uci": {
					"system": ["*"],
					"wireless": ["*"]
                	}
		}
        }
}

#add entry to /etc/config/rpcd
config login
        option username 'admin'
        option password '$p$admin'
        list read adminuser
        list write adminuser

#update /etc/passwd
admin:x:200:200:admin:/var:/bin/ash

#update /etc/shadow
admin:$1$6Foyv2Pv$G/P624gFKZWld7YZkpQdP1:18278:0:99999:7:::

#set the admin user password using passwd command


/etc/init.d/rpcd restart

Take a look at these files on your system and see how it's currently being used.

@Lazar-Demin I haven't used overlays but I just checked what files it can create, you can see the options here:

Since OpenWrt is OSS you can download the community version of CLion and give it a shot.

The docs are here

Thought it was worthwhile to make members aware that CLion IDE by Jetbrains supports code completion for DTS and DTSi.

This was news to me, I've always done this manually, but CLion makes it sooooooo much easier.

Hi @martinpedros the LED on the dock indicates the charging status of the LiPo battery, which if you have no battery will indicate by flashing all the LEDs, they call this "Stationary Mode". Not really intuitive I know, but that's the documented functionality.