Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    gadget-man
    @gadget-man
    let ipURL = "https://api.ipify.org/?format=json";
        HTTP.query({
          url: ipURL,
          success: function (body, full_http_msg) {
            let response = JSON.parse(body);
            li("IP: " + js(response.ip));
    etc...
    Sergio R. Caprile
    @scaprile
    I would guess that the server will not ask for mutual authentication... so you should not need your own certificate and key; just the CA certificate to validate the server's claim of being himself should do.
    I don't know if mbed-TLS would complain if this cert is SHA-1 signed, but since you say it worked for Liviu, if the site is the same, I'm clueless.
    Jan
    @janko.valiska:matrix.org
    [m]
    Hi, please is there some general guide how to make esp8266 AP+STA mode stable? Currently sometimes the client is disconnected from AP and connected back within one second.
    AP and STA uses different channels
    Jan
    @janko.valiska:matrix.org
    [m]
    Hi, are wifi credentials stored unencryoted in the mongoose configuration file? Or are they readable by viewing FW binary?
    DrBomb
    @DrBomb
    Unencrypted on the mongoose config yes, readable by the viewing FW binary. Yes too
    But the latter could be deterred by enabling flash encryption
    Jan
    @janko.valiska:matrix.org
    [m]
    but probably flash encryption isn't case for ESP8266 right? I found that flash encryption is added to ESP32, but i didn't found something similar for ESP8266.
    DrBomb
    @DrBomb
    Oh yeah, I thought you were working with the esp32
    Deomid Ryabkov
    @rojer
    right, ESP8266 lacks any kind of confidentiality protection capabilities
    Márk Antal Csizmadia
    @mark-antal-csizmadia

    Hi all,

    I've had an issue lately with changing STA the configuration and reconnecting to a network.

    My goal is: to reconfigure WiFi credentials without having to reboot. The use case here is that the WiFi credentials were initially misconfigured (wrong password, for example), and I would like the end user to be able to correct the password without rebooting the device. The configuration is done through connecting to the ESP32 in AP mode, so I don’t want the bonding between device and user (mobile phone via app) to be broken.
    My actions are: I’ve tried two methods. Each begins with setting the new credentials with mgos_sys_config_set_wifi_sta_ssid() and mgos_sys_config_set_wifi_sta_pass().

    I’ve tried (1) calling mgos_wifi_disconnect() and then mgos_wifi_connect(), (2) trying to reset the WiFi sta like so:

    struct mgos_config_wifi_sta sta_config = {
            .enable = true,
            .ssid = ssid,
            .pass = pass,
    };
    
    mgos_wifi_disconnect();
    
    if (mgos_wifi_setup_sta(&sta_config)) {
            mg_rpc_send_responsef(ri, "ok");
    } else {
            mg_rpc_send_responsef(ri, "couldn't set up sta");
    }

    where ssid and pass are the new SSID and password, respectively, and (3) seting up the entire WiFi modoule (both AP and STA) such that

    mgos_wifi_setup((struct mgos_config_wifi *)mgos_sys_config_get_wifi())

    in which case the AP is also restarted, which I do not want. I only want the STA to restart, but not the AP.

    The result I see is: I’m still connecting to the same network. Nevertheless, observing

    sta_cfg.ssid

    and

    sta_cfg.pass

    seems to have the correct credentials. However, my ESP32 still seems to be connecting with the previous, incorrect password.

    Trying to set an incorrect password, for example, will not disconnect me from the AP.
    My expectation & question is: I expect to be able to smoothly change WiFi creds while the device is running without any restarts. Is this possible?

    I would greatly appreciate your help! Have a great day!

    hdmt-hock
    @hdmt-hock

    Hello, anyone know of solution to change mos latest 74 to mos release 2.19 in mac mojave?

    $ mos version
    The Mongoose OS command line tool
    Version: 74
    Build ID: 74~brew
    Update channel: latest

    I have tried "mos update release", brew uninstall and re-install, delete and install. At the end still end up mos latest.

    ALSO, mos local build on mac os is stuck at "Docker arguments: run ..." for the last 2 hr, cancel build and retry still the same, but was working at least 1 build this morning. However, running mos build in AWS EC2 linux with mos release 2.19 is working.

    janko.valiska
    @janko.valiska:matrix.org
    [m]
    Hi guys, on ESP8266 platform is time_t defined as number of seconds since epoch? Or is it in another(platform defined) units? If yes, is there some nice way how can i convert value stored in time_t to seconds?
    Liviu
    @nliviu
    @janko.valiska:matrix.org Yes.
    janko.valiska
    @janko.valiska:matrix.org
    [m]
    Sorry i placed 3 questions. So your yes belongs to first question? 😀
    Liviu
    @nliviu
    Sure.
    janko.valiska
    @janko.valiska:matrix.org
    [m]
    Thank you
    Liviu
    @nliviu
    @hdmt-hock Did you try this?
    Giuseppe Bertucci
    @giuseppe-bertucci

    hello folks, having a weird behaviour in mos tool while trying to add a library to my project.
    The library is https://github.com/ellavas/mongoose-lib-hlw8012, when I checkout the project and build it by itself it works fine (it returns a nice Lib saved to build/lib.a)
    Although, when I add the dependency to my project with

    libs:
      - origin: https://github.com/ellavas/mongoose-lib-hlw8012

    I get the following error:

      CC    /home/leo/dev/mos/app-demo/build/gen/build_info.c
      LD    /home/leo/dev/mos/app-demo/build/objs/app-demo.elf
    /opt/Espressif/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/9.2.0/../../../../xtensa-lx106-elf/bin/ld: /home/leo/dev/mos/app-demo/build/objs/mgos_deps_init.c.o:(.rodata.mgos_libs_info+0x104): undefined reference to `mgos_mongoose_lib_hlw8012_init'
    collect2: error: ld returned 1 exit status
    /home/leo/dev/mos/app-demo/deps/modules/mongoose-os/platforms/esp8266/Makefile.build:360: recipe for target '/home/leo/dev/mos/app-demo/build/objs/app-demo.elf' failed
    make: Leaving directory '/app'
    make: *** [/home/leo/dev/mos/app-demo/build/objs/app-demo.elf] Error 1
    Error: exit status 2

    any ideas or workaround? I'd be happy to use directly the lib.a file if there's a way to do so (though is not ideal)

    Giuseppe Bertucci
    @giuseppe-bertucci

    answering my own question for other people benefit, I could either use

    binary_libs:
      - mylib/mylib.a

    as per documentation, or override lib name (the init method apparently is built conventionally using lib name) via

      - origin: https://github.com/ellavas/mongoose-lib-hlw8012
        name: hlw8012 # this makes the trick
    thanks for being my rubber duck. peace
    Jan
    @janko.valiska:matrix.org
    [m]

    Hello guys, please, how to use correctly TLS client authentication when doing HTTPS request? Is it enough to set path to client certificate and key files:

      struct mg_connect_opts opts;
      opts.ssl_cert = "client_cert.pem";
      opts.ssl_key = "clien_key.pem";

    And then pass this opts struct to mg_connect_http_opt function? Because when i do this as i described i get errors like:

    [Mar  1 10:40:35.710] mongoose.c:4912         0x3fff194c received handshake message
    [Mar  1 10:40:35.786] mongoose.c:4912         0x3fff194c mbedtls_ssl_flush_output() returned -78 (-0x004e)
    [Mar  1 10:40:35.786] mongoose.c:4912         0x3fff194c mbedtls_ssl_write_record() returned -78 (-0x004e)
    [Mar  1 10:40:35.786] mongoose.c:4912         0x3fff194c mbedtls_ssl_send_alert_message() returned -78 (-0x004e)
    Jan
    @janko.valiska:matrix.org
    [m]
    Call to API endpoint doesn't work if client authentication is enabled on server side. No matters if i set or not connect opts.
    hdmt-hock
    @hdmt-hock

    @hdmt-hock Did you try this?

    Thank you @nliviu, the links works only after "brew unlink mos". This step is necessary if you have "latest version" installed and want to change to "released version". Please update the documentation. Just a comment, I did know those steps in the link and it did not works previously (meaning before 25 feb), I guess something has changed. Is "mos update release" and "mos update latest" still works?

    Liviu
    @nliviu
    I don't think mos update {release,latest} ever worked with brew.
    Brian Brietzke
    @bbrietzke

    confused on the parameters given for timer_callback, in particular how to convert the void pointer to an int.

    #include "mgos.h"
    
    static void timer_cb(void * arg) {
      //int ledPin = *((int *) arg);
      int ledPin = *(int*) arg;
    
      static bool s_tick_tock = false;
    
      LOG(LL_INFO,
          ("%s uptime: %.2lf, RAM: %lu, %lu free on pin %i", (s_tick_tock ? "Tick" : "Tock"),
           mgos_uptime(), (unsigned long) mgos_get_heap_size(), (unsigned long) mgos_get_free_heap_size(), ledPin));
    
      s_tick_tock = !s_tick_tock;
    
      if (ledPin >= 0) {
        mgos_gpio_toggle(ledPin);
      }
    }
    
    enum mgos_app_init_result mgos_app_init(void) {
      int ledPin = mgos_sys_config_get_board_led1_pin();
    
      if (ledPin >= 0) {
        mgos_gpio_setup_output(ledPin, 1);
      }
    
      mgos_set_timer(1000 /* ms */, MGOS_TIMER_REPEAT, timer_cb, &ledPin);
    
      LOG(LL_INFO, ("pin %i", ledPin));
    
      return MGOS_APP_INIT_SUCCESS;
    }

    i have tried the above code on an esp32 and an esp8266 and the results are pretty consistent. the LOG statement in mgos_app_init() will show the correct pin number for LED1 ( 2 or 13 ).

    when i try to dereference the void pointer in timer_cb(), it doesn't show the the same number as i pass in; on the esp8266 it will almost always show -1, while on the esp32 it will vary widely.

    my intent is to be able to have the same callback function just with a different pin number assigned to it ( and wait time fwiw ) depending on the remain logic.

    I'm sure i'm doing something silly and any help would be appreciated. Thank you.

    DrBomb
    @DrBomb
    You will have to brush up in C @bbrietzke As you're passing the pointer of a variable defined inside the init. When the timer gets called, that memory pointer will long be invalid
    You will either have to define the variable as a global one and access it from the timer, or allocate the int to the heap and pass the allocated pointer to the userdata to be cast back on the callback
    Brian Brietzke
    @bbrietzke
    Thank you @DrBomb, you are right. Here is what the correct ( or at least works for me ) code looks like:
      int *ledPin = (int *) calloc(1, sizeof(*ledPin));
      *ledPin = mgos_sys_config_get_board_led1_pin();
    DrBomb
    @DrBomb
    k
    Sergey Lyubka
    @cpq
    That is a weird construct. I think it should be something like this:
    int *pin1 = &mgos_sys_config_get_board()->led1_pin;
    mgos_set_timer(1000, MGOS_TIMER_REPEAT, timer_cb, pin1);
    System configuration is a singleton, therefore getting addresses from nested structures should work just fine.
    @bbrietzke allocating pointers, like you did, then assigning , would not make it reference a correct address, so your code seems wrong
    Jan
    @janko.valiska:matrix.org
    [m]
    Hi guys, is there option in mos tool to create RELEASE version of FW binary? So all strings like /home/MY_USER_NAME/... are stripped from final FW binary? Thank you.
    abveenwall
    @abveenwall
    So, stupid question.. Is the 'mos clone' command broken or am I totally missing something ?
    Liviu
    @nliviu
    It looks like it's broken
    mos clone https://github.com/mongoose-os-apps/empty
    Error: empty: Local copy in "empty" does not exist and fetching is not allowed
    /src/cli/build/swmodule.go:262:
    /src/cli/main.go:198: clone failed
    abveenwall
    @abveenwall
    That's what I get across platforms as well. Okay, we'll do it the manual way - thanks @nliviu
    Liviu
    @nliviu
    Never used mos clone. Always using git clone.
    abveenwall
    @abveenwall
    Could be that the quickstart guide is old. I didn't have git on my Windows (work) machine, but that's what I'll end up doing for my linux devhost.
    Sergio R. Caprile
    @scaprile
    I've seen this on the new release, there are two user reports here. I've had no problem in 2.18.0 (I've not upgraded yet)
    hdmt-hock
    @hdmt-hock
    Hello, the mos build --clean --local --platform=ESP8266 is stuck at Docker arguments: run --name mos_build_ ... again. This is my 2nd build today, I had terminate a previous build and restart the build. The last time the mos build stuck at docker was about a week ago when using mos latest '74. Now with mos release 2.19.1 , same issue. Is this related to docker limitation of 200 container pull per 6 hr?
    I did had a successful build yesterday but with 2.19.0 specified in mos.yml, today I remove and use ${mos_version}
    hdmt-hock
    @hdmt-hock
    Interestingly, ${mos_version} works in AWS EC2 linux but not on mac os mojave. I replace the ${mos_version} with 2.19.1 in mac os mojave and the build runs.
    hdmt-hock
    @hdmt-hock

    currently the mos build local on mac os mojave stuck at

    CC    /Volumes/Hidromotic/github/hidromotic/acueducto_sarah/pozo/esp/build/gen/mg_build_info.c

    for the last hour. CTRL-C and rebuild, restart docker and rebuild, clean and rebuild.. stuck at the above line. Is mos under some maintanence schedule?

    Sergey Lyubka
    @cpq
    Local builds are local, there could not be any maintenance
    hdmt-hock
    @hdmt-hock
    I left the build running since yesterday and still stuck in ´mg_build_info.c´
    Marcus Hoffmann
    @hoffmann-m

    Hi, I try to upgrade my project to Mongoose-OS v2.19.1 and get this error wiht local build:

    Generating esp32.project.ld
    LD /home/mark_wahlberg/git/my-app/build/objs/my-app.elf
    /opt/Espressif/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/mark_wahlberg/git/my-app/build/objs/mosapp/libmosapp.a(mgos_freertos_core_dump.c.o):(.text.mgos_freertos_core_dump+0x20): undefined reference to `mgos_freertos_extract_regs'
    /opt/Espressif/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/mark_wahlberg/git/my-app/build/objs/mosapp/libmosapp.a(mgos_freertos_core_dump.c.o): in function `mgos_freertos_core_dump':
    /home/mark_wahlberg/git/my-app/deps/freertos/src/mgos_freertos_core_dump.c:40: undefined reference to `mgos_freertos_extract_regs'
    collect2: error: ld returned 1 exit status
    make: *** [/home/mark_wahlberg/git/my-app/build/objs/my-app.elf] Error 1
    /opt/Espressif/esp-idf/make/project.mk:563: recipe for target '/home/mark_wahlberg/git/my-app/build/objs/my-app.elf' failed
    make: Leaving directory '/app'

    Does anyone have a clue for me?

    Sergio R. Caprile
    @scaprile
    opened issue 41 regarding mos clone failing
    Liviu
    @nliviu

    @hoffmann-m In the current version of esp-idf (4.2-r1), mgos_freertos_extract_regs definition is protected by CONFIG_ESP32_ENABLE_COREDUMP_TO_UART.

    In previous versions there was simply a #if 1.

    Liviu
    @nliviu
    @scaprile You reported in the wrong repo. It has been fixed in mongoose-os/mos#55.