Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Mark
    @markterrill
    @DrBomb that's super handy, so we just need to be able to 'snapshot' an existing folder tree using the 'version' argument, to output a point in time mos.yml
    I know this sounds stupid, but yesterday building against 'release' there were compilation issues as deps/modules/mbedtls was on 2.16.11-cesanta1 instead of 'master'. As such it would be handy for the mos tool to have an option to output a copy of your mos.yml with all the version tags it would suggest for the current latest. This could be based on whatever was used by the person who pushed the most recent master release
    @cpq 1. commit/branch pinning, yes!
    re 2, i'm honestly not sure what the implications of that is. I think the biggest issue is development is currently being done against master. That's not usual practice and means at a point in time it may be broken in comparison to what has been committed on related libraries.
    so I think there is 3.
    Mark
    @markterrill
    item 3. development should be done on an universal feature branch name. IE 'feat-IDF44' and that branch name is used on MOS and all correlated library projects so it's super easy to know if you're using bleeding edge to checkout the matching branch on all libraries (and if it doesn't exist for a library, use master)
    "latest" really is just shorthand for master, but master should be working and in sync across libraries without build issues
    item 4. release candidates. before pushing to master can a release candidate be created and provided for a few weeks for a few folk to thumbs up. can be casual approval by consensus. this is great for visibility and warning that things are changing, just good project hygiene. I'm happy to help with documentation on addressing breaking changes, ie 'how to update your code', based on what I need to do to fix our codebase which uses a broad range of libraries.
    Mark
    @markterrill
    item 5. OTA etc compiled library versioning. I don't know how often it changes or needs changing, but some kind of version tagging beyond 'latest' seems likely
    hope this helps!
    Mark
    @markterrill
    (on reflection i think item 4 is highly optional and may be too much overhead, but it would be neat to highlight somehow when there are new versions being fetched by 'latest')
    Sergey Lyubka
    @cpq
    I don't actually see any difference between my (1), which is version pinning to a specific hash of any library and the mongose-os repo itself, and Mark's "snapshot" thing. To me, that is absolutely the same. If you're able to pin any library and mongoose-os repo to a specific hash, you're effectively "freezing" the whole tree. @DrBomb , can you confirm that that is already possible - i.e. one can set specific commit hashes to any lib and the mongoose-os repo, please?
    Sergey Lyubka
    @cpq
    w.r.t. developing in master vs specific feature branch ... what stops doing it right now? I don't see any reason why not developing in feature branch, then merging to master when ready.
    Also, I'd like to make it so any community member with write access can cut a release, so there is no dependency on Cesanta. We can just export closed-sourced OTA libs somewhere, and release process could just pick those up.
    Deomid Ryabkov
    @rojer
    well, it's already the case and is exactly how release is cut - we just take whatever is published at latest and re-upload it to the release tag.
    apart from github access, cutting a release requires special access to mongoose-os.com to upload mos binaries and docker hub access to push images
    Deomid Ryabkov
    @rojer
    and also gpg key access to sign ubuntu packages
    Deomid Ryabkov
    @rojer
    also, adding new platform support with OTA support is not currently possible entirely in the open: while updater core interfaces are public, and an open backend could be written to interface with it, prebuilding binary libraries needs to be configured for ota libs
    Mark
    @markterrill
    @cpq yes you're right, 'snapshot' is just a neat way of referring to the functionality we're talking about. It also infers there is a neat mechanism to switch between snapshots.

    w.r.t. developing in master vs specific feature branch ... what stops doing it right now? I don't see any reason why not developing in feature branch, then merging to master when ready.

    nothing! Just a few maintainers to manage that process and merge PR's into a feature branch rather than master, then when everything on that branch is building neatly against tests then it can be pushed to master

    i'm also wondering what other business models may work instead of OTA licensing, ie is it easier to open source OTA and have a different payment/reward mechanism ?
    Mark
    @markterrill
    though it doesn't sound like OTA actually has many versions and requirement for frequent updates
    Sergey Lyubka
    @cpq
    @rojer thanks! Well, an access to mongoose-os.com could be sorted out, and uploads allowed for mongoose-os commiters
    DrBomb
    @DrBomb
    @cpq You can pin library versions using the approach I just mentioned. If I wanted to build against an specific mOS commit, I would clone the repo, checkout the commit and pass the --repo flag with the path to the build command. As far as I understand, that sets that folder as the mOS source, hence building against a specific commit. I have NOT used that flag in some time now, but I believe that's how it works.
    Sergey Lyubka
    @cpq
    @DrBomb yep, understood, thanks for the clarification!
    DrBomb
    @DrBomb
    :+1:
    Deomid Ryabkov
    @rojer
    @DrBomb if all you need is to pin to a specific hash, all you need is mongoose_os_version: HASH
    however, mongoose-os is just a module, so the above is equivalent to this:
    modules:
      - location: https://github.com/cesanta/mongoose-os
        version: HASH
    gadget-man
    @gadget-man
    @DrBomb that doesn’t currently work - I recently tried pinning to a recent hash, but the build then fails:
    /mongoose-os/src/mgos_net.c: In function 'mgos_update_nameserver':
    <command-line>: error: too many decimal points in number
    Sergey Lyubka
    @cpq
    I suspect CS_STRINGIFY_MACRO(MGOS_DEFAULT_NAMESERVER)
    gadget-man
    @gadget-man
    Yes exactly. The point is that I tried to pin a hash and it doesn’t work due to other changes. In this instance it’s due to a simple change elsewhere. However the point is if releases aren’t frequent, it would be handy to be able to pin a commit. Currently it seems you can’t - this was just an example.
    Deomid Ryabkov
    @rojer
    i think making version accept a timestamp could be the solution. version: @2022-08-09 for example
    only need to modify checkout code to examine commit log to find the right commit, then setting the three *_version variables (mongoose_os_version, libs_version, modules_version) will pin everything.
    Alex Stout
    @astout
    Hi all, I am looking to optimize the firmware build size on esp32, observing the logs, I can see some compile flags happen like make…. ’-j’ ’10’ but I don’t see any -O usage, so I thought by defining flags in the mos.ymlthat I would see my compile flags get inserted somewhere in the build process. But I do not.
    cxxflags: # or cflags (I’ve tried both)
      - "-Os"
    1. Are there any optimizations being used when building?
    2. How can I successfully add -Os to the compilation to optimize for size?
    Deomid Ryabkov
    @rojer
    -Os is already the optimization we use, so there's no point
    Alex Stout
    @astout
    Oh darn. Thanks for the clarification.
    gadget-man
    @gadget-man

    i think making version accept a timestamp could be the solution. version: @2022-08-09 for example

    That would be great

    Sergey Lyubka
    @cpq
    The other way would be to blend the core libraries into the mongoose-os repo .. or is it a bad idea?
    dhanrajpchoudhary
    @dhanrajpchoudhary
    Does mongoose supports ESP32-S3 based chip
    paulparrish
    @paulparrish

    MQTT queue never sends
    I'm seeing odd behaviour where occasionally the MQTT queue is not drained, i.e. mgos_mqtt_num_unsent_bytes() returns a positive value that never decreases.
    The device is an ESP32 connecting via PPPoS (Quectel M65) to AWS infrastructure
    The system never recovers from this. Incoming MQTT published from AWS test client work ok, and then after a while they are no longer received by the device.

    Internet connectivity is fine though - i have a button press that performs a HTTP GET from a web site, and this continues to work retrieving content, indicating outgoing and incoming data is flowing through the PPPoS connection.

    Has anyone experienced anything like this? or have idea.
    Thanks
    Paul.

    Deomid Ryabkov
    @rojer

    The other way would be to blend the core libraries into the mongoose-os repo .. or is it a bad idea?

    it's a lot of shuffling and won't solve the problem completely, i'd say no, we should come up with a better way of pinning versions, like the date/time suggestion above.

    Sergey Lyubka
    @cpq
    So basically, a version: "2022-02-02 10:00:00" would pin every library to the most recent commit that is no later than the specified date. That sounds good
    gadget-man
    @gadget-man
    I think that would help resolve 90% of the issues flagged here. Community users would then be able to reliably switch between mos or lib commits and help to identify bugs.
    Sergio R. Caprile
    @scaprile
    @paulparrish I suggest you enable PPP debugging (lwIP's PPP can do that) and check your logs to see if "the queue is not drained" or your Quectel/mobile ISP/AWS are not doing their job as you expect. Please detail your mOS versions and post to the forum a minimum piece of software probing your point. Last time I checked AWS everything worked smoothly, and mobile providers are prone to causing trouble to persistent data connections unless you are a big customer paying for that.
    paulparrish
    @paulparrish
    @scaprile Thank you for your response Sergio, much appreciated.
    Is there a specific way of enabling PPP debugging please? other than just raising the debug level?
    I've tried a couple of different ISPs, and normal HTTP GET works when MQTT wont which to me suggest the link is up, albeit the mobile provider may still be causing issues with certain types of data.
    Sergio R. Caprile
    @scaprile
    @paulparrish The link might be up but for HTTP GET your connection goes up and down quickly and for MQTT is a persistent connection; we've had some issues with persistent data connections in this side of the world some years ago when I was somewhat involved with cell modems.
    You didn't say which platform you are using and I assume it uses lwIP. Somewhere you can tell lwIP to log its PPP netif traffic. I've already had a similar conversation with someone at the forum, start with this thread and please open a new one with your findings.
    Sergio R. Caprile
    @scaprile
    Are you checking your MQTT connection status ? The MQTT send function will just queue whether you are connected or not and IIRC the AWS functions mostly call the MQTT functions.
    paulparrish
    @paulparrish
    @scaprile I have event handlers for MGOS_EVENT_CLOUD_CONNECTED and MGOS_EVENT_CLOUD_DISCONNECTED and record the current cloud connected status and will only send MQTT if considered to be connected. I assume the underlying MQTT connection will only be discovered as disconnected when either a periodic keep alive fails or a request to publish an MQTT message fails. I've seen a device discover it is disconnected, and reconnect, but the scenario i originally described it doesn't determine this on MQTT publish, just sits there doing nothing, when I'd really be hoping for a disconnect and reconnect process.
    Of course, this may be a mobile provider issue, but even so I'd hope after a timeout a reconnection would happen.
    Is there a better way to determine the underlying connection is broken?
    I'm using MOS v2.20.0 developing in C, with the stock lwip library from github.
    I'm looking at the other forum thread you linked, so very much appreciate your help.
    spare-it
    @spare-it

    Hello !
    Since july, I noticed that mos tool is failing on my mac computer . I am getting errors opening the serial port when running some of the commands like mos license or mos config-get with the following message

    Error: write: /dev/cu.usbserial-[XXXX]: file already closed

    On the other hand, mos flash and mos console seem to be working fine.
    The device are working OK, as I am able to check through the console.
    I tried, upgrading mos to 2.20.0, de-installing and re-installing mos completely and a fresh mos install on another MAC computer (using the instructions from this page Mongoose OS Documentation).
    I keep having the same issue,
    Do you have any recommendation on how to troubleshoot this issue ?