@György-Farkas alright, after the upgrade to 0.2.x content and configuration is persisting across power cycles. Thank you for your help. It's too bad the UI told me that the old version I had was the latest version. If it had prompted me to upgrade I wouldn't have had any of these issues!
Now the new web interface is missing the "Settings" app. Trying to figure out what package that is contained in so I can install/reinstall that!
I flashed a snapshot version of OpenWRT and I noticed that the reboot command doesn't work.
Onion omega2+ stays in a like infinity loop and it doesn't respond until I perform power cycle.
I also noticed that this bug has been solved in latest releases of onion firmware (Ω-ware).
Is there anything I can do to solve this bug on OpenWRT branch?
What is the official software solution for that?
The underlying issue here has been covered many times before.
The Omega 2+ has an ill-chosen flash chip, which cannot expose its full capacity unless operated in a 4 byte mode which is incompatible with the configured expectation at boot.
There is no actual working poweroff command, and there never has been one. However, programs that reboot without putting the flash chip back in a boot compatible mode end up hanging in a tight loop at boot, giving the impression of being sort of "off".
Also note that unexpected reboots, such as triggered by a watchdog will also result in a hang, rather than a successful boot.
As the Omega 2 (non +) flash chip fits entirely in 3-byte addressing mode, it should not experience this problem.
Flash chip commands can be found in the relevant data sheets, as well as the U-Boot and Linux Kernel sources.
Thank you @Zheng-Han - a little out of my depth with that for now :( I think I must rather focus on my original issue with the i2c driver freezing up randomly when fetching data from the arduino. I need to find a way to restart the driver without having to resort to a reboot and losing data.
If I put omega2-ctrl gpiomux set pwm0 pwm in a script.sh file and run it then I get the following message:
unknown group/function combination.
Does anybody has an idea how to resolve this issue?
you could try downloading & installing a fresh copy of b160 firmware. there is something amiss in the current install/package. you can spend many hours trying to find the problem or get a new copy of the firmware and see if that works.
Chris, thank you for your help, I will order a converter to be able to act quickly.
My problem update:
After several attemps (power on-off) Omega Onion led became solid and it finally connected to the Wi-Fi network and I reached it through web browser interface via WiFi. I don't know what triggerred this failure mode.
However there is a problem with the Omega; my device is running continuosly and after about 1 day I cannot connect it via web browser at local network. I experienced this problem more than once. It still functions and active at cloud, strangely does not respond at local network(WiFi) via Putty or web browser.
Reboot Omega and if you have network it will actualize your location/date/time.
I have everything set as per your post but the point is when you force a reboot by killing /etc/rc.local it brings up a fixed time, not a network time. With this extra line in /etc/rc.local it obtains the network time on reboot.
Strictly speaking, the Macbook is under no obligation to provide more than 100 mA to a device that doesn't properly negotiate for it, which I don't get the sense the power dock has the capability to do.
In practice it does seem though that it can work with a good 5v-3.3v regulator on many computers . I will say that my personal experience with doing so is using a well designed switching regulator, which converts energy unlike a simple linear regulator - ie, the computer has to supply somewhat less current at 5v than the device is drawing at 3.3v.
Ultimately, power issues are the #1 cause of reboots (especially around the time of wifi startup) and all of ultimate power source, regulator, and cabling should be considered... I had a system I was ready to give up on, tried a different (and confusingly, much smaller physically) source and regulator, and it's been wonderfully stable since.
I have managed to reproduce these steps several times and so I'm documenting it. The trick as far as I can tell is that when you visit the spinning wifi-setup screen while you run the wifisetup steps in a ssh terminal window, it somehow manages to persist the changes correctly.
If you run into a changing WiFi issue... try this.
Power on your Onion Omega +2.
On your computer or laptop - switch your wireless connection to your device omega-####.local where #### represents the last four numbers of MAC address.
Once you are connected, you should be able to SSH onto the device:
Now you want to switch to a web browser at this time and open the following address:
You will be presented with a login, go ahead and login.
On the web-browser console, open "Settings" and then click on "WiFi-Settings", you will get the usual spinning circle (as described on this thread above).
While this is spinning, switch back to the SSH terminal and type
Follow instruction and pick the correct WiFi you want.
At the end, it will say "> Restarting wifimanager for changes to take effect".
Reconnect on your computer or laptop WiFi back to "omega-####.local" device.
SSH in if you're disconnected. If you use a keep-alive, you will be reconnected on the SSH terminal.
On the SSH terminal, issue the following command:
ifconfig | grep "inet addr"
This will display all the IP's used by your various devices on your network. You should an additional one like this.