Copyright ©

Mongoose OS Forum


Managing Changes to Mongoose OS?

mookiedogmookiedog Washington, USA

Apologies for my evident frustration:

I tried rebuilding my app today after bringing it home from where it has been placed in service for about a week. First off, it wouldn't build anymore. The routine I had been using [mgos_net_add_event_handler()] is apparently not defined anymore. It appears that routine has been replaced with something else what takes different parameters. In any case, it was faster to delete the old call rather than dig through github change logs to figure out what had changed and how to deal with the change. Since it was not strictly necessary for the test I needed to try, I just deleted the old call. The app built after that, so that was good.

After loading the new firmware into my device, I noticed that the log messages from the app were showing me that the SNTP setting of the clock which always used to occur is not happening anymore. All my status messages are claiming to be from 1969. Not sure what changed there, but the SNTP clock setting has always been automatic to this point.

Then, I pushed my pushbutton to generate an MQTT message and publish it to Amazon via AWS, like I always do. It's a convenient on-demand way to perform a basic end-to-end test. The system coredumped. That is a new, consistent, and irritating behavior.

So yet another thing has changed underneath my app.

What is the official Mongoose OS methodology for how users should be managing changes to Mongoose? Maybe there is some way, but I have not seen it in any of the examples. Is there some way to tell the build system that I don't want the latest and greatest libraries? Right now, my mos.yml looks like this:

- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:
- origin:

Hmmm. Actually, it doesn't look like that, but the code formatter markdown feature on this forum is really flakey. But in any case, it would appear to my untrained eye that the libraries are being fetched directly from github, so they probably reflect the latest, greatest, and potentially undocumented changes. Or is there some better method to allow users to manage incorporating the changes that occur to Mongoose?

Again, sorry for the frustration.


  • edited January 2

    Not to worry ... the real fun will come when you deploy some commercial product to customers far and wide using 1.x and then discover all of your missing API's and changes when you want to do an OTA or add a new feature ... that's the good stuff ... and don't think you are safe keeping at 1.x and never updating, if you do that then the compiler messages will tell you to upgrade and that you're building at your own risk ... that's when you'll be in flavor country ...

  • Hi. Sorry for that frustration.

    So first of all, it looks like you're using the "bleeding edge" latest mos, I'd recommend switching to the released version, which is, first, more stable, and second, it doesn't update under you feet unless you ask for it explicitly. The command for switching to release is: mos update release. The current release is 1.23; if you want to use the previous one (to make your code compile with mgos_net_add_event_handler()), you could specify exact version for mos update, like this: mos update 1.22.1. After that, the mongoose os core and libs are frozen at that revision and will never change unless you update it with mos update or from the web ui.

    don't think you are safe keeping at 1.x and never updating, if you do that then the compiler messages will tell you to upgrade and that you're building at your own risk

    Mos tool will indeed remind you about the newer version available, but there's nothing about "building at your own risk". Released versions are kept unchanged: the core and all libraries, etc. The only case when "your own risk" becomes relevant is when you use some newer library which didn't even exist at the time the version you're using was released. But assuming you only change app's code and don't add new libraries, you're safe using e.g. 1.22.1 for ages.

  • mookiedogmookiedog Washington, USA

    Ah. I would get messages like these during the build process:

    By the way, there is a newer version available: "1.23" (you use "1.22.1"). Run "mos update" to upgrade.

    Being an obedient sort, I would always upgrade when prompted. I did not make the connection that the version of the mos executable itself would implicitly define the library versions.

    After getting your reply, I downgraded from what I thought was 1.23 back to 1.22.1. The result is that my system builds again, SNTP works again, and pressing my button does not cause a core-dump anymore. So that worked, and thanks.

  • Ok. However, I can't reproduce problems with SNTP, on 1.23 it still works for me.

  • pedalPusher68pedalPusher68 Boston
    edited January 3

    Is it now (1.23) required to explicitly include in your mos.yml file in order for sntp config settings to be compiled without error?

    I'm having in trouble getting a build (local) to work and in the build.log, I see a line:

    While parsing /../../mongoose-work/apps/i2c_scan_app/build/gen/mos_conf_schema.yml: 'sntp.update_interval: Cannot override, no such entry'
  • If your app uses sntp, then yes, you have to include sntp library (this functionality was in the core recently, now it's moved to the library)

  • Ok, thanks. I got it working. Next question on this. Do you provide a link with release notes, breaking changes, etc.(critical stuff) for your releases?

  • That's a totally fair point, and sadly we should be more diligent with this. We are trying to be better: as you see in the releases list we even have some release notes since 1.20 :) but yes, the important SNTP thing was missing there, sorry (I just added it).

    So the release notes is the place to look for the description of breaking and non-breaking changes. We will get better on maintaining it.

    Thanked by 1pedalPusher68
  • sh4nnongohsh4nnongoh Singapore

    Just to put it out there, I also find it very frustrating that the builds break very frequently.

    And yes, I am using ./mos.exe update release.

    Thanked by 1mookiedog
  • mookiedogmookiedog Washington, USA

    There seems to be something "sticky" with how all this cloud build system works in a fashion that is not obvious to a non-expert. This thread started because I was using 'release' for a while because it is the default, and as a new user, I just use the defaults. Then, I got hit with an API change, so I downgraded to 1.21 as per the instructions above (thanks!). That helped for a while with no problems. This week, I tried to get local libraries to work so I could work around a bug in the OneWire library. That effort turned into 2 completely lost days, but that's a different issue. But part of that experience was to upgrade back to 1.23 to see if that helped. It did not, so I downgraded back to 1.21. But now my system does not build anymore even with 1.21. I get:

    'Error: neither sources nor prebuilt binary exists for the lib "ota-shadow" (or, if a library doesn't have any code by design, its mos.yml shouldn't contain "sources")
    Error: build failed'

    Some part of my build process or library management or some random mos.yml file seems to be stuck somewhere it should not be. After two days, my only path forward seems to be to admit defeat, and figure out the API change that came with 1.23. So yeah, it's frustrating.

  • @mookiedog , did you try clean builds? (with the --clean flag)

  • mookiedogmookiedog Washington, USA

    Yes, and I flushed my build directory.

  • Please paste your mos.yml and full build log.

Sign In or Register to comment.