Best posts made by crispyoz

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.

@huntc The comments in the spi-nor driver seems to explain it.

if (nor->addr_width == 4 &&
    nor->read_proto != SNOR_PROTO_8_8_8_DTR &&
    !(nor->flags & SNOR_F_4B_OPCODES)) {
	/*
	 * If the RESET# pin isn't hooked up properly, or the system
	 * otherwise doesn't perform a reset command in the boot
	 * sequence, it's impossible to 100% protect against unexpected
	 * reboots (e.g., crashes). Warn the user (or hopefully, system
	 * designer) that this is bad.
	 */
	WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
		  "enabling reset hack; may not recover from unexpected reboots\n");
	nor->params->set_4byte_addr_mode(nor, true);
}

@huntc @Lazar-Demin is probably the only one who can answer that question since Warp Core is not open source and I can't test as I am not using Warp Core anymore. I look at this from a different perspective. Should I make my product design reliant on Warp Core. The answer I came to myself is a resounding NO! Onion developed Warp Core as the open source MT76xx driver was a flakey mess, which in turn made the Omega WiFi a flakey mess. As time passed, a commercial organisation invested money into the open source MT76xx WiFi and the result has been a reliable and flexible MT76xx driver for OpenWrt. I question why would Onion further develop Warp Core when the standard drivers are reliabe, more flexible and under continued development. so therefore why would I hitch my wagon to component with a questionable future.

I'm not suggesting that it is better to use vanilla OpenWrt, the Onion customised release comes with nice scripts/tools to make the Omega experience very sweet, only that relying on Warp Core might not be the best long term strategy.

@huntc This runs the /sbin/firstboot script which performs jffs2reset which erases the overlay partition. The overlay partition contains the packages you install etc

@huntc This is an image of an Omega2S+ with the lid taken off, you can clearly see the flash chip so it's not hard to access..

@DumTux Can you execute the command:

echo 11 >/sys/class/gpio/export

Then check /sys/class/gpio/export/gpio11 is created

If it is then you can set to input mode using the command:

echo in >/sys/class/gpio/gpio11/direction

@CyrilSneer I have some string sitting on my desk. Can you tell me how long it is please?

This is the same as your question, there is no specific information so it is not possible to answer your question. As a first step perhaps you can share:

1. What language you are using (script/C/python etc)
2. A sample of your code
3. How you are building your code
4. What model Omega2 are you using
5. What firmware version you are using

All the basics

@dkaranassos I did something similar and commissioned 250 custom PCB with the fault. I became quite skilled at cutting tracks and soldering jumpers. Not ideal but deadlines and budgets ....

@tony-ter-neuzen Congratulations on getting up to speed with building your first custom firmware!! You should now feel "super relaxed".

It may not fix your immediate issue, only time will tell, but it will allow you to tinker and experiment with all of what the Omega2+ and OpenWrt have to offer, then build the best solution for your devices. One of the things I love about the Omega2+ is that it gets you started quickly with a clearly defined set of hardware and software and once you are ready to take off the floaties you can step up to the next level.

Now you need to learn how to build your own repository so you can deploy your custom updates to your devices. Lots of fun!

@tony-ter-neuzen I'm not aware of any issue similar to your report, however I do have some thoughts.

The MtPsWatchDog does come from the Warp Core driver but perhaps because it utilises some of the MT WiFi driver code. Since the Warp Core driver is closed source that is about as much as I can deduce.

I can't help but wonder if there is a combination of issues here. When the Omega2+ is searching for WiFi it does consume more resources, if at the same time your app is also consuming more resources due to the failing connection, perhaps this exacerbates the issue. Did you try the same test without your software running, and perhaps just run a script to utilise the connection?

You can also use the standard MT WiFi driver which allows you to turn off ap or sta separately.

@Nagarjuna-Reddy I suspect the issue is that when you connect to the Modbus host then disconnect, the port on the host is not closed and the device can only accept a single connection. So you need to make sure that you close the port on the client side each time you or subsequent connections will fail.

I'm making some assumptions here because I don't have details of the host device, but the logic is sound.