Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    DrBomb
    @DrBomb
    Is there a way to reenable the idf's logging calls?
    I'm trying to troubleshoot some ethernet issues and I was wondering if I would get more info with their messages
    Deomid Ryabkov
    @rojer
    wdym re-enable? they are enabled
    DrBomb
    @DrBomb
    Hmm, right. I guess i thought some were getting eaten up but they're showing up, sorry!
    Jan
    @janko.valiska:matrix.org
    [m]
    Hi, is somewhere some good BLE MESH community? some forum or discussion rooms, etc... thanks.
    Davide Maggioni
    @TheCrypt0
    Is there a way to communicate with the modules console without UART? I'm trying to use https://github.com/mongoose-os-libs/rpc-ws but when calling mos console --port ws://192.168.1.69/rpc I get the error:
    Error: /src/cli/dev/dev_conn_impl.go:171: remote error 404: No handler for Dash.Console.Subscribe
    /src/cli/dev/dev_conn_impl.go:190: 
    /src/cli/console.go:239: 
    /src/cli/main.go:198: console failed
    I'm not trying to communicate via mDash, I just want a way to connect to multiple devices in the local network without having to connect them to the pc.
    igorkblr
    @igorkblr

    Good day everybody. Having problems with mos build using version 2.19.1. mos build fails on deps.

    https://bpa.st/5MRA

    each next run fails on other lib, i see no checking out messages, similar to the ones I have with older version builds
    rpc-service-ota: Checking out 2.10.2..

    ps. Don't know how to embed pastebin into the message

    gadget-man
    @gadget-man
    Try a clean build - it looks as though the wifi lib in your deps folder is incomplete Error: open /home/exe/Work/Slide/mos/slide/deps/wifi/mos.yml: no such file or directory. Try running mos build --clean
    igorkblr
    @igorkblr
    i do run builds with --clean flag. The actual command invoked in docker is
    mos build --clean --platform esp32 --local --verbose --libs-dir ./deps/ --lib cron:deps/cron --lib crontab:deps/crontab --lib location:deps/location --lib jstore:deps/jstore --lib rpc-service-wifi:deps/rpc-service-wifi --lib slide-file-logger:deps/slide-file-logger --no-libs-update 2>&1
    gadget-man
    @gadget-man
    You’re calling no-libs-update. Try removing that and deleting your deps folder for the wifi lib?
    igorkblr
    @igorkblr
    Thank you, moved further. Now i deal with c-code erros, that didn't exist before - but this is known area.
    igorkblr
    @igorkblr

    For some unknown reason I get an error about undefined mgos_sys_config_get_device_id()
    search for the definition does not find any reference in header files. Where it is defined?

    /home/exe/Work/Slide/mos/slide/src/rpc_service_slide.c: In function '\''slide_svc_get_info_handler'\'':
    /home/exe/Work/Slide/mos/slide/src/rpc_service_slide.c:45:51: error: implicit declaration of function '\''mgos_sys_config_get_device_id'\''; did you mean '\''mgos_sys_config_get_device'\''? [-Werror=implicit-function-declaration]
    "calib_time: %d, pos: %.2f, touch_go: %B}", mgos_sys_config_get_device_id(), mgos_sys_ro_vars_get_mac_address(),
    ^~~~~~~~~
    mgos_sys_config_get_device

    Liviu
    @nliviu
    @igorkblr It is generated in build/gen/mgos_config.h
    igorkblr
    @igorkblr
    strange, it is not there
    gadget-man
    @gadget-man
    I’m seeing a strange situation on a local test device - it failed to connect to my AP for almost 12 hours. Looking at the logs, normally I see a log entry similar to the following:
    mgos_wifi_sta.c:516 Trying Reldene AP c4:41:1e:67:69:1a RSSI -64 cfg 0 att 1
    however when it fails to connect, it boots and shows this instead:
    mgos_wifi_sta.c:516 Trying Reldene AP 00:00:00:00:00:00 RSSI 0 cfg 0 att 1
    Is the fact that it doesn’t display the mac address of the AP purely because it hasn’t found it, or should we expect that data to be saved from previous connections?
    (we know the AP was online, as another device 3m away stayed connected and online throughout…)
    Deomid Ryabkov
    @rojer
    all zero AP is "last resort" entry, i.e. we don't specify any BSSID and let the wifi library pick one (this is our way of handling hidden SSIDs, as they are not returned in scan results)
    it means that there were no APs in scan results and instead this wildcard entry was added (in case SSID is hidden)
    unless this network uses hidden SSIDs, this means that something went wrong during scan and no results were returned
    gadget-man
    @gadget-man
    Hmmm, so sounds a lot like a temporary version of the problem I was having on the device the other day (which still won’t connect). Weird this about this was it reconnected after about 12 hours and has been fine ever since.
    Deomid Ryabkov
    @rojer
    try increasing wifi-related debug level: debug.file_level=mgos_wifi=3,esp32_wifi=3
    it will print scan results it gets
    igorkblr
    @igorkblr
    how comes that there is no definition of mgos_sys_config_get_device_id() in generated mgos_config.h file? Do i need any specific define or settings for that in mos.yml file?
    Deomid Ryabkov
    @rojer
    @igorkblr that's really weird. it's defined in the core library, that is included in all apps - https://github.com/mongoose-os-libs/core/blob/master/mos.yml#L29
    nevertheless, can you check that you have core lib?
    i remember that you're using some ancient version, like 2.10
    igorkblr
    @igorkblr
    i am using the latest now, 2.19.1
    Up to 2.14 everything builds just fine. Problems start with 2.14
    abhibhatia98
    @abhibhatia98
    Hi , I am doing ota over mqtt, just curious to know, when does fw_version inside device packet got incremented ?? Do I need to increment it itself after doing OTA for getting firmware version status in future or it has some other use case?? And how can I access this inside the program, I have not found any documentation, please help.
    Deomid Ryabkov
    @rojer
    @igorkblr can you share generated final manifest? build/gen/mos-final.yml, you can do it privately if you prefer
    @abhibhatia98 fw_version comes from the version field of mos.yml
    Marcus Hoffmann
    @hoffmann-m
    @rojer Since friday all our gateways that were connected to GCP via mqtt.googleapis.com are offline! Some devices connected via mqtt.2030.ltsapis.goog are still online. The log output for mqtt.googleapis.com: The certificate is not correctly signed by the trusted CA. We are running mongoos os 2.18.0. The GlobalSign R2 ca should not expire before 2021-12-15. Do you hear or know soming about this issue? Are some Google CAs missing from the ca.pem?
    Deomid Ryabkov
    @rojer
    @hoffmann-m Google has changed the certificate chain. it is still signed by a globalsign root but by a different one
    this one expires in 2028
    i guess they decided to switch in advance of root expiration
    to my knowledge, they did not announce their intention or what they will be switching to... our ca bundle does not ship this newer globalsign root, so devices were cut off...
    previosuly they used OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign, now they use C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
    why wouldn't they switch to one of their roots, i have no idea...
    i mean, they had to switch the chain, might as well switch to the same as their LTS APIs use
    but no. so here we are.
    Marcus Hoffmann
    @hoffmann-m
    thank you, do you have a source for this information?
    Deomid Ryabkov
    @rojer
    openssl s_client -connect mqtt.googleapis.com:8883 -showcerts
    they have two intermediates, last of which is signed by globalsign
    Marcus Hoffmann
    @hoffmann-m
    i see. by the way, we chose google cloud because it offers interesting security aspects in comparison. but now we have to integrate a backchannel, even for the lts.
    Deomid Ryabkov
    @rojer
    lts should be fine
    but using this root on their regular endpoint was a bad idea from the start...