1. 27 Sep, 2020 9 commits
  2. 18 Sep, 2020 2 commits
  3. 15 Sep, 2020 1 commit
  4. 13 Sep, 2020 1 commit
  5. 09 Sep, 2020 1 commit
  6. 08 Sep, 2020 1 commit
  7. 07 Sep, 2020 2 commits
  8. 05 Sep, 2020 1 commit
  9. 04 Sep, 2020 2 commits
    • vsky's avatar
      Fixes `net.ifinfo` failure · e28cf8d9
      vsky authored
      e28cf8d9
    • galjonsfigur's avatar
      SoftUART module fixes and code simplification (#3104) · e7620b06
      galjonsfigur authored
      * SoftUART fixes:
      
      - Simplify code by using lua_L* functions and using userdata properly
      - Fix some edge-cases
      - Add more examples to documentation
      
      * Don't de-register interrupt hook if there is more RX instances
      
      * More bug fixes and registering simplification with luaL_reref and unref2
      
      * Correct documentation of SoftUART module
      e7620b06
  10. 03 Sep, 2020 1 commit
  11. 01 Sep, 2020 1 commit
  12. 30 Aug, 2020 1 commit
  13. 29 Aug, 2020 3 commits
  14. 23 Aug, 2020 2 commits
  15. 22 Aug, 2020 2 commits
  16. 11 Aug, 2020 1 commit
    • Caleb Mingle's avatar
      mqtt: fix connfail callback · e547c2a0
      Caleb Mingle authored
      I've not been able to get the mqtt `connfail` callback to work.
      
      I'm consistently receiving `method not supported` errors:
      ```
      application.lua:53: method not supported
      stack traceback:
              [C]: in function 'on'
              application.lua:53: in main chunk
              [C]: in function 'dofile'
              init.lua:18: in function <init.lua:6>
      ```
      
      Example code:
      ```
      function on_connection_failed(client, reason)
          print("mqtt connection failed: " .. reason)
      end
      
      m:on("connfail", on_connection_failed)
      ```
      
      I believed this to be caused by the incorrect length comparison for `connfail`
      that is updated here.
      
      Once I changed that, the error went away, however the callback was never called.
      
      I believe the callback was never called because of an incorrect assignment.
      
      However, I saw this somewhat confusing description in the docs so this
      assignment may be expected?
      > The second (failure) callback aliases with the "connfail" callback available through :on(). (The "offline" callback is only called after an already established connection becomes closed. If the connect() call fails to establish a connection, the callback passed to :connect() is called and nothing else.)
      e547c2a0
  17. 08 Aug, 2020 2 commits
  18. 03 Aug, 2020 1 commit
    • Emdioh's avatar
      Correct negative results in DHT driver (#3210) · bf15299c
      Emdioh authored
      
      
      * DHT module: fix the handling of negative temps.
      
      The macro handling the conversion from the 2 bytes buffer to a double
      was handling negative values by checking the sign bit and taking the
      negative value of the number minus the sign bit.
      Unfortunately this does not work as the negative values are represented
      in 1's complement, so for instance -1 was becoming -32767
        * +1 = b0000_0000_0000_ 0001
        * -1 = 1111_1111_1111_1111
      
      This replace the spacial code with a signed 16 bits value.
      
      * Refactoring: removes some code duplication.
      
      * Fixed the conversion of the 8/16 bits values
      Co-authored-by: default avatarMarco Dondero <marco@dondero.eu>
      bf15299c
  19. 07 Jul, 2020 1 commit
  20. 30 Jun, 2020 1 commit
    • Datong Sun's avatar
      Fixed an regression that MQTT client timer is disarmed prematurely when · 95f5191c
      Datong Sun authored
      connecting to server.
      
      Inside af426d03, the `mqtt_socket_timer`
      function was modified so that instead of checking the presense of
      allocated `mud->pesp_conn` structure, `mud->connected` field was used
      on determining if the timer need to be disarmed.
      
      However, this is not entirely correct. If the TCP socket is actively
      connecting and haven't timed out yet, then `mud->connected` is also
      `false` and the timer will think the connection is broken and
      disarms itself. This has two consequences:
      
      * The connection timeout counter is no longer decremented and checked
      * After connection succeeds, keepalive heartbeat is no longer being
        sent (#3166). This is particularly noticeable in MQTT over TLS
        connections, because those usually takes longer than 1 second
        to finish and the timer would had chance to execute before connection
        is established
      
      This commit checks the presense of `pesp_conn->proto.tcp` pointer
      instead, which was allocated in the same place as the (old) `pesp_conn`
      struct, and according to my test indeed fixes the above issue.
      95f5191c
  21. 22 Jun, 2020 1 commit
  22. 20 Jun, 2020 1 commit
  23. 17 Jun, 2020 1 commit
  24. 16 Jun, 2020 1 commit