Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Liviu
    @nliviu
    @gadget-man You need to install libftdi1-dev
    sudo apt install libftdi1-dev
    gadget-man
    @gadget-man
    Thanks all I’ll try that. @markterrill do you still want the dns-sd code? Sounds as though you’ve got it sorted...
    gadget-man
    @gadget-man
    OK now I’m getting a different error (having installed libftdi1-dev):
    go version go1.15.7 linux/arm
    GOOS= GOARCH= CC= CXX= \
      /usr/local/go/bin/go build -mod=vendor -tags '' -ldflags '-s -w ''' -o mos github.com/mongoose-os/mos/cli
    # runtime
    /usr/local/go/src/runtime/mgclarge.go:142:26: mheap_.treapalloc undefined (type mheap has no field or method treapalloc)
    /usr/local/go/src/runtime/mgclarge.go:193:8: mheap_.treapalloc undefined (type mheap has no field or method treapalloc)
    /usr/local/go/src/runtime/mgclarge.go:249:9: undefined: scavengeTreapNode
    /usr/local/go/src/runtime/signal_unix.go:525:5: crashing redeclared in this block
        previous declaration at /usr/local/go/src/runtime/signal_sighandler.go:15:5
    /usr/local/go/src/runtime/signal_unix.go:530:5: testSigtrap redeclared in this block
        previous declaration at /usr/local/go/src/runtime/signal_sighandler.go:20:5
    /usr/local/go/src/runtime/signal_unix.go:544:6: sighandler redeclared in this block
        previous declaration at /usr/local/go/src/runtime/signal_sighandler.go:33:69
    /usr/local/go/src/runtime/unaligned2.go:12:6: readUnaligned32 redeclared in this block
        previous declaration at /usr/local/go/src/runtime/alg.go:374:40
    /usr/local/go/src/runtime/unaligned2.go:17:6: readUnaligned64 redeclared in this block
        previous declaration at /usr/local/go/src/runtime/alg.go:382:40
    Makefile:93: recipe for target 'build-mos' failed
    make: *** [build-mos] Error 2
    (I’ve also updated go to 1.15.7)
    Liviu
    @nliviu
    I tried to upgrade in place to go 1.15.13 and got build errors.
    After sudo rm -rf /usr/local/go and installing 1.15.13 it builds ok.
    gadget-man
    @gadget-man
    Thanks @nliviu I’ll try that now.
    Mizer
    @amizer12
    @DrBomb - the thing is that i can hear relay clicking when id do a GRPIO.write (4,1) and it is going On - but the GPIO.Read(4) always read 0 - always, no matter if the gpio is o or 1. relay on or off
    Not sue if that is related to teh fact that this GPIO runs in output mode ( GPIO.Read reads GPIO16 that i have setup as input fine - it reads 0 or 1 properly )
    Liviu
    @nliviu
    @amizer12 You need mgos_gpio_read_out to read the status of a GPIO setup as output.
    gadget-man
    @gadget-man
    I’m nearly there! It works if I call mos/mos, but if I try just mos I get command not found. I’ve already got export MOSPATH=$HOME/mos in my .bashrc, but guess I’m missing somethign still?
    Mizer
    @amizer12
    @nliviu Thanks ! this is missing from js.api as read in js.api for GPIO uses mgos_gpio_read - i`ll expose it withi a sample project and see if it runs fine, if so i will crate a pull request to get this added to the js .api as well
    Liviu
    @nliviu
    @gadget-man Or you can move it in /usr/local/bin which should be in the PATH.
    gadget-man
    @gadget-man
    Ok. Do I move the whole mos directory there?
    Liviu
    @nliviu
    NO, only the executable.
    gadget-man
    @gadget-man
    Ah oK.
    TY
    Liviu
    @nliviu
    NP :)
    DrBomb
    @DrBomb
    @amizer12 If the relay's clicking it should be working. What's the problem then?
    abhibhatia98
    @abhibhatia98

    Hi, I am working around an project with esp8266 and pi loaded ubuntu as host. I have flash the firmware to esp and connected to n/w. The logs shows it first try to connect with n/w and get failed with error code 3 or 202. After 2/3 second again try to connect with n/w and got connected. And shows the ip as well and also on network device, the esp shows up in connected device list. After that I ran mos call Sys.GetInfo it shows :

    `{
    .....parameter....,
    "wifi": {
    "sta_ip": "",
    "ap_ip": "",
    "status": "connecting",
    "ssid": ""
    }
    }' while the network device still shows it as connected
    Any idea what could be the issue ?

    Sergio R. Caprile
    @scaprile
    Did you sniff your network ? Did you check your AP logs for further info ? Perhaps your device reboots when mos connects via serial and that is why you don't see anything in Sys.Getinfo, have you checked that ?
    abhibhatia98
    @abhibhatia98
    @scaprile I have not checked AP logs, but I have checked that esp has n/w connectivity it is able to connect with cloud. The issue is sys.GetInfo doesn't show wifi info correctly
    Sergio R. Caprile
    @scaprile
    That is quite a claim, since it works for every one else except for you.
    You describe two issues:
    1- If your device fails to connect and then connects later, sniff your network and check your AP logs.
    2- If you don't see your IP in Sys.Getinfo, that can be because perhaps your device reboots when mos connects via serial to issue the command.
    If your device is connected to WiFi, has an IP address, and you compiled in a web server, you can get the info by connecting via HTTP or using Websockets (I know it is not very useful since you have to know the IP beforehand... but at least you will see that the RPC returns the correct information); just use the --port flag followed by the URL.
    You can also connect through MQTT
    abhibhatia98
    @abhibhatia98
    @scaprile well I am on work's place n/w so can't access the logs. But I came up with an observation the above mentioned issue cames only when device (esp) is connected to pi, while I connected the same device to my windows laptop and call Sys.GetInfo it gives me correct values.
    chrisbucher
    @chrisbucher
    Hi guys! I am having some problems with rpc_acl, namely that the ch_type is ignored:
    Here is my rpc_acl:
    [
    {"method": "", "ch_type": "WSS_out", "acl":""},
    {"method": "FS.", "acl":""},
    {"method": "", "acl": "-"}
    ]
    This should allow any users request from WSS_out (mdash), but block any other rpc on all channels (except for FS.), right?
    With this rpc_acl, I can call any RPC from any channel, so it is not working.
    If i change the first line to {"method": "
    ", "ch_type": "WSS_out", "acl":"admin,-*"}, i need the admin creds to call any rpc but even using the mos tool over UART.
    Any advice? My goal is to allow all rpc from mdash, but block some, allow others with admin and leave some free for all.
    Deomid Ryabkov
    @rojer
    @chrisbucher i think some symbols in the acl you posted got eaten by markup, can you put it inside
    triple backticks
    chrisbucher
    @chrisbucher
    [
      {"method": "*", "ch_type": "WSS_out", "acl":"*"},
      {"method": "FS.*", "acl":"*"},
      {"method": "*", "acl": "-*"}
    ]
    @rojer thanks.
    Sergio R. Caprile
    @scaprile
    IIRC, you have to use +* for "allow all users". I haven't played with ch_type, though
    Deomid Ryabkov
    @rojer
    + is implied, so it's optional. it should work like @chrisbucher says, let me take a look
    default is to deny if there is no match, so last line is also optional
    but good to have to make things explicit
    Deomid Ryabkov
    @rojer

    @chrisbucher it works for me, with this exact content in rpc_acl.json and rpc.acl_file=rpc_acl.json (did you remember to set that?), i get 403 when trying to go via HTTP:

    $ curl http://192.168.11.161/rpc/Sys.GetInfo
    {"code":403,"message":"unauthorized"}

    with debug.level=3 on the device, i see this in the logs:

    [Jul  6 16:20:33.371] mongoose.c:15306        0x3ffdd63c conn 0x3ffe4b9c from 192.168.11.104:60248
    [Jul  6 16:20:33.377] mongoose.c:2752         0x3ffdd63c 0x3ffe4e98 1073629196 0
    [Jul  6 16:20:33.385] mongoose.c:2759         0x3ffe4e98 tcp://192.168.11.104:60248
    [Jul  6 16:20:33.391] mgos_http_server.c:180  0x3ffe4e98 HTTP connection from 192.168.11.104:60248
    [Jul  6 16:20:33.399] mg_rpc.c:563            0x3ffe4e38 '' HTTP
    [Jul  6 16:20:33.403] mg_rpc.c:493            0x3ffe4e38 CHAN OPEN (HTTP 192.168.11.104:60248)
    [Jul  6 16:20:33.412] mg_rpc.c:520            0x3ffe4e38 GOT PARSED FRAME: '' -> '' 799428820 args ''
    [Jul  6 16:20:33.419] mgos_vfs.c:283          rpc_acl.json -> /rpc_acl.json pl 1 -> 1 0x3ffbaac4 (refs 1)
    [Jul  6 16:20:33.428] mgos_vfs.c:377          open rpc_acl.json 0x0 0x1b6 => 0x3ffbaac4 rpc_acl.json 1 => 257 (refs 1)
    [Jul  6 16:20:33.438] mgos_vfs.c:536          fstat 257 => 0x3ffbaac4:1 => 0 (size 120)
    [Jul  6 16:20:33.444] mgos_vfs.c:536          fstat 257 => 0x3ffbaac4:1 => 0 (size 120)
    [Jul  6 16:20:33.451] mgos_vfs.c:564          lseek 257 0 1 => 0x3ffbaac4:1 => 0
    [Jul  6 16:20:33.457] mgos_vfs.c:564          lseek 257 0 0 => 0x3ffbaac4:1 => 0
    [Jul  6 16:20:33.464] mgos_vfs.c:410          close 257 => 0x3ffbaac4:1 => 0 (refs 0)
    [Jul  6 16:20:33.472] mgos_rpc.c:425          Called 'Sys.GetInfo' via 'HTTP', ACL: '-*'
    [Jul  6 16:20:33.480] mg_rpc.c:636            0x3ffe4e38 SEND FRAME (85): {"id":799428820,"src":"shelly25-test3","error":{"code":403,"message":"unauthorized"}} -> 1
    since UART is not allowed, this doesn't work too:
    $ mos call Sys.GetInfo
    Using port /dev/ttyUSB0
    Error: /build/mos-latest-Da4ye0/mos-latest-202106171938+f08e2c6~focal0/cli/dev/dev_conn_impl.go:171: remote error 403: unauthorized
    so, everything appears to be working.
    abhibhatia98
    @abhibhatia98
    Hi, I am sending some data over mqtt. Previously I defined mqtt server by running below command. mos config-set mqtt.enable=true mqtt.server=192.168.43.164:1883 from mos tool. Do any one share how can I defined it through program internally ??
    Deomid Ryabkov
    @rojer
    @abhibhatia98
    mgos_sys_config_set_mqtt_server("...");
    mgos_sys_config_set_mqtt_enable(true);
    mgos_sys_config_save(&mgos_sys_config, false, NULL);
    chrisbucher
    @chrisbucher

    @rojer what mgos version are you using? I am using 2.17.0
    I tried it again starting from scratch, but the channel is still ignored. I can confirm that I have set rpc.acl_file=rpc_acl.json.

    tried with the previosly posted rpc_acl.json: the same result with different connection types: UART, mdash, HTTP. Every RPC is allowed.
    Another weird thing: If I modify the first line to: {"method": "*", "ch_type": "WSS_out", "acl":"admin,*"} , any command requires admin auth. Shouldn't this line allow the users admin and * (so actually anyone, even without creds?)

    abhibhatia98
    @abhibhatia98

    @rojer Thanks it works.

    @abhibhatia98

    mgos_sys_config_set_mqtt_server("...");
    mgos_sys_config_set_mqtt_enable(true);
    mgos_sys_config_save(&mgos_sys_config, false, NULL);

    I need one more help do it possible to access Sys.GetInfo RPC call or some how device info structure inside C file ? I can access the same inside js file by using RPC.Local, but no idea how can I use that inside the c file

    Deomid Ryabkov
    @rojer
    @chrisbucher channel type matching was only added in 2.19 (mongoose-os-libs/rpc-common@f7c7fe5)
    you can cherry-pick that commit if you like
    @abhibhatia98 why would you want a json blob in C? what are you trying to do?
    abhibhatia98
    @abhibhatia98
    @rojer well I just want to send device info packet(mac.app_name,version,ssid,ip,id) over mqtt to some edge device.
    I wanted it like as the device powered it connects to n/w and then send info packet over mqtt. So I wanted the above parameter in C
    I have below code till now
    if (mgos_wifi_setup_sta(&sta_config)) { //retrieve device info like mac,app,version //mgos_mqtt_pub(topic, deviceInfo, strlen(deviceInfo), 1, 0); } else { //mg_rpc_send_responsef(ri, "couldn't set up sta"); }
    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