Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 21 of 21

Thread: New project code named: teensquitto

  1. #1
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837

    New project code named: teensquitto

    Currently working on the MQTT version of teensy controller, code names teensquitto (teensy & mosquitto)

    Libraries interfaced/imports:

    GIT version of esp8266 arduino, lwip2 MSS-536 stable on adafruit huzzah breakout
    Ported ESP8266WiFiSTA.h transparency functions and some corrections from the teensywifi_controller code which is running excellent.
    All ESP handlers are disabled, they are the WORST, buggy, unstable handlers that get in the way while adding code, and caused random lockups. It's stable without them.
    All MQTT/WIFI states are updated automatically to the teensy library, with auto resubscription to the controller's listening topic at QoS 2 (on connect/reconnect)
    Uses user/pass authorization for mosquitto broker, and clientId for the topic (teensy name) can be anything you wish to "construct".
    AsyncMqttClient.h library will be used, with all handlers and Ticker.h removed, resulting in a much, much more stable and control environment to work with with project.
    Teensy and ESP both run at 1megabaud uart rates in this setup.

    As it currently stands, a decision on the topic convention for this project is still up for ideas.
    At first I started with:
    Code:
    teensquitto/location/clientId/
    Then, that would mean implementing a user to implement a location name for his clientId, which, can be any name you want as well. (bedroom?livingroom?penthouse?africa?)
    Then my current idea, no location, but instead connect and return the MAC address of the ESP to the teensy library so the user can keep track of it.

    Code:
    Connected to 192.168.2.122 on port 1883...
    Subscribed as 'teensquitto/35:43:3A:43:46:3A/amber'


    since the clientId's can be generated at the teensy constructor, you can have 2 mcus with the same clientid, and a unique mac, and eventually when i add group support, you'll be able to run teensies symmetrically. I will be using QoS2 for this project to ensure deliveries.

    One of the abilities I will add is the transparency functions of the async mqtt library as well, perhaps also with transparent callbacks, all functions are run off teensy, and the ESP stores it's config in eeprom as well.

    there will also be a few debugging in USBSerial:
    Code:
    DEC:   114 114 6 
    WiFi status 6: WL_DISCONNECTED
    DEC:   114 114 3 
    WiFi status 3: WL_CONNECTED
    and the current constructor for the server:
    Code:
    teensquitto amber = teensquitto("amber", &Serial1, "192.168.2.122:1883", "user", "pass");
    current constructor to enable ESP8266WiFiSTA.h transparency:
    Code:
    teensquitto WiFi = teensquitto("WiFi", &Serial1);

    if anyone has suggestions on a topic structure to follow for this type of controller setup as my previous projects, I'm open to listening, especially before I start working on the teensy endpoints.
    One thing to keep in mind is the idea to control 2 or more teensies with a single payload packet, and the ideal approach to activate/deactivate a group method. Maybe calling .group() on the class object could send a "+" for the mac address location as an example to have all clientIds of same name to take the command. Just an idea as it's all i got right now...

    Tony

  2. #2
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    aside from the payloads/topics i decided to start working on the library modules:

    the esp will be sending a heartbeat every second over uart unless mqtt traffic applies, traffic will keep the heartbeat from running, this, in turn, would allow the library to know when the physical connection is there or not before processing commands. asuming there are no heartbeats or valid payloads in-stream, the library will assume esp connection issue and set all functions offline until the esp is connected and pulsing again. safe to assume also, with the transparency implementation, you could send the esp into deepsleep mode while the library disables itself, and then probably use Snooze to make teensy goto sleep as well, and reset the esp on teensy wakeup, or just use the CH_EN pin. Regardless, the pass-through functions are there, you can write your own code and wiring for that kind of setup.

    the server status (mqtt) as well as the server latency will be automatically synchronized with the library. this will allow functions to use dynamic timeouts (latency plus non-exagerated timeouts (ex. several hundred msecs instead of 2-3 secs)) depending on traffic latency. short to say, this can leave us to assume the client went offline and disable the object’s functions until it comes back online. the same applies to the client. the modules are already in place and work, just a matter of traffic to assign them. this should enable the library to be in non blocking mode shall the client/server/esp decide to go offline.

    the wifi credentials and the mqtt server will be connected in async as well, so the library wont block your normal loop() while it captures the status updates mid-stream. the subscription for the teensquitto server is automatically resubscribed and handled on the esp end whenever the server goes online.

    currently, if a last known good mqtt configuration was set, it will automatically run on a reboot/reset. this leads to faster boot and connection times for everyone. you could also add your own logic if necessary in teensy setup (WiFi.status()) or perhaps use internal library functions (not configured yet) to check connection/connection details of the esp before resubmitting WiFi.begin(......) in setup. begin() will also transfer all client/server credential client data to the esp for initialization as well. ex. amber.begin() will configure the server from the previous post, client will be similar but it in itself will use a different constructor for the client.

    Tony
    Last edited by tonton81; 01-03-2018 at 08:05 PM. Reason: typos from iphone :)

  3. #3
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    ive replaced the heartbeat system at the esp end with an autosync at the teensy end. the pulses are every 250ms with a timeout of 1 second

    3 states will be returned to the teensy host:
    1) when the esp is disconnected
    2) when the esp is connected
    3) when the esp is reset/rebooted

    they will be later addressed to a handler of which the user can set his custom payloads/subscriptions on an esp reset for example, like, a startup handler

    im still stuck on a topic system made specifically for an interconnect mcu system with parallel output

    what do you guys think of this?

    given the current constructor for server in post #1, the given object will connect the esp as
    teensquitto/mac_addr_of_esp/clientid

    so, considering that i been thinking of how to handle the clients/servers? i think i might make it multi server like my previous wifi library, however, i may also write in a disabler for remote control in case you dont want remote control of certain teensy.

    an issue with the above is, a mac address is assigned to a client id for remote access, the problem, is you need to keep track of your macaddress/client in order to control it, perhaps the client constructor might include:
    “macaddress/client”

    that would be easy to control.

    next issue, how to keep track of misplaced macids and clients
    i will probably have the clients post to an /online topic where teensy could publish request a list of active clients with their mac addressed topics, this could be feasable

    we still need to lean into multi teensy control, which means same named client ids, and instead of mac addressed, how about we construct a:

    “+/clientid”

    for a same named clientid, this will give us an object which controls both devices, and allows the mac addressed contruct to work for individual control as well. at that point we have single, and multiple controlled objects



    i will further have to implement a no return policy on the grouped objects, due to the multiple replies, i think this method will only be good for sending data only, ex, digitalwrites, pinmodes, but not digitalreads, unless, i would forward the payloads to teensy end for processing, and perhaps have arrays for certain hardware registers that the code could fill for each object, that would be totally insane, but possible lol...

    i will prolly also use round trip latency averages updated every packet and use a multiplier of X value for optimistic timeouts

    would the topic structure above be ideal for this type of setup or can anything be improved upon? i need a convention base to start on else itll be hard to change midway/later on.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,178
    Interesting - I have a few esp8266's around - and Teensy of course. Having a uniform way to connect would be nice. I saw MQTT (Grill Control linked) when I looked at this MyWebServer linked before that worked well as I lightly used it. That has evolved to this [ feb 2017 ] : myWebServerAsync

    I'm not sure if that project might have anything worth looking at? Assuming he expanded it - it would allow SPIFFS file read/write and web pages fixed and on the fly from ESP w/teensy and OTA code uploading through Arduino.

  5. #5
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    well with the transparency intact you might be able to run spiffs as-is on teensy

    teensy would actually use the spiffs on the esp as if it were locally, but really served off the esp...

    good no?

    the esp wifiscan.ino demo ran on teensy...
    Last edited by tonton81; 01-08-2018 at 11:04 AM.

  6. #6
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    ill take a look to see if i can port over the spiffs references/functions on the teensy end, if its possible of course, but thats a great idea, i could do the eeprom too but im currently using it to store the startup configuration for quick access of successful mqtt/wifi connections issued from the teensy host. but that wont stop us from accessing remote teensies eeproms

    if you like me to include other stuff im always open for adding improved features

    Tony

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,178
    Tony - just pointing it out in case he has evolved something useful - and perhaps more stable on the ESP end than what you were running up against ['All ESP handlers are disabled, they are the WORST, buggy, unstable handlers']. The SPIFFs stuff was handled on the ESP - as a native webserver - having good access to 1 or 2+ MB could be handy. I followed his link some time back to his MQTT project - but saw it was to his grill and not sure how it related to the then current webserver code as I was using it. Not something I'm currently looking at - but if it helped you get a robust solution for later that would be nice. Teensy could use a good healthy way to WiFi.

  8. #8
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    i got the async mqtt handlers playing nice and asynchronously now
    thanks for the ideas
    i plan to bring most if not all features over to teensy

  9. #9
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,178
    Nice, good luck. I have a few raw EPS8266's, and some Teensy form factor ones from onehorse as he developed them and a 10 pack of the OAK ESP's from that KS - all sitting unused.
    Maybe I didn't understand your intro posts well enough - When I looked at MQTT it had a server for storage/distribution somewhere? Are you putting that on Teensy+ESP?

    From the little I was doing with the NailBuster github code it was nice - and at the time he was responsive to my feedback. It had NTP time from web and other bits in. He turned off the OTA as unsafe then added it back under debug - there may be supported security for that now? He had accounts and password protection on using the MyWebServer code to access and update the contents of SPIFFS web - and even user account pages for adjustments. It also had support for compressed pages to save space on the SPIFFS area IIRC.

    Have I missed the utility of the newer ESP32 units - or did it not take off? I saw SparkFun made a Thing for it . . . The ESP8266 seemed like a great Teensy addon to offload the WiFi and its fitful nature from impacting Teensy operation. And handy the Teensy could reprogram the ESP when OTA didn't work.

  10. #10
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    for the server im currently using mosquitto on my i7 pc while i write out the esp+teensy protocol

    for the good news: teensy now has this working. an exact replica of an esp command!

    Code:
    File f = SPIFFS.open(“/f.txt”,”w”);
    looks like i will be bringing SPIFFS over to teensy if everything turns out well! theres alot of libraries to go thru so itll be a bit of time to grasp the layout as i never worked on SD/SPIFFS before. im just sampling demos whoile porting over the functions

    i havnt added any webserver but it doesnt stop you from adding it either. i will also port the wifi client over to teensy as well
    after im done ill prolly have to look into those teensy esps as im just working with adafruit breakout esp’s atm, would be nice to have a small footprint for teensy in the end. i never touched OTA so im not sure on that topic yet as im programming them over uart currently

    the code should still work on esp32 as it uses the core functions in transparency mode, the benefit would be additional gpios and busses as well as bluetooth radio etc, but i dont think for a project as this people would but a esp32 to link up to a teensy unless they wanted combined bluetooth access, i could add those additional features, but not before the esp8266 functions are complete.
    Last edited by tonton81; 01-08-2018 at 11:13 PM.

  11. #11
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,178
    Seems like you are in a good place and making headway. Wanted to say I was watching - passively - and point out that server code that was looking good before and now improved wasn't sure if it might be a better ESP base platform.

    OTA is nice, I was remote desktop'd to my downstairs computer running the IDE for ESP and programming that over WiFi so I didn't need to hassle with what was then the IDE rebuilding everything on device change.

    I was only noting the ESP32 hadn't caught my eye in making any huge splash since it was released - not like the 8266 did when it got onto Arduino. Indeed - unless Bt was important - that would be overkill for a 'WiFi processor' add-on. Not something I'd dump all my 8266's for if I went back to them.

    Are you using std Serial to talk to the ESP? And using that to do proxy uploads to the ESP through Teensy? The onehorse units soldered on with control pins to handle reprogramming over Serial and other needs when OTA got trashed.

  12. #12
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    yes, im using both TX channels of serial and serial1, and serial rx channel of the esp, actually rx0 i use for debugging, tx1 goes to teensy rx1 and rx0 goes to teensy tx1, teensy to esp uses 1 megabaud communication with a dynamic buffered uart protocol that prioritizes the transfer when a header is matched, ive never lost data with it yet and it worked well streaming 500 byte fastled arrays non stop using the default uart buffer of 64 bytes

    Tony

  13. #13
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    Dillema time!

    Getting SPIFFS to work on teensy is not as hard as getting File class to cope with the protocol layout. I have an idea to just drop using the File class altogether since most of the SPIFFS commands are ran on the object, of which I could add the missing File functions to the SPIFFS object's class.

    As it stands, the command yesturday did work, and did return a bool, but this is what happens:

    Yesturday we sent File f = SPIFFS.open(“/f.txt”,”w”);, the ESP has a global File f; set and what my actual protocol does is run this on the ESP end:
    f = SPIFFS.open(“/f.txt”,”w”);

    all that is fine and dandy, but, what do we do about the File f on teensy end? I'm stumped, and making them work together a protocol like this is looking to be a nightmare.
    I have a suggestion though, since most of the SPIFFS functions are ran on it's own object, do we really need File class?

    I suggest the following, we have a functional command on teensy side:
    SPIFFS.open(“/f.txt”,”w”);
    that runs this on ESP side:
    f = SPIFFS.open(“/f.txt”,”w”);

    in order to not make our lives complex, including library code, would it be hard for a user who will be using this library to do this:
    Teensy end:
    bool f = SPIFFS.open(“/f.txt”,”w”);
    if ( f ) { .. do something }

    ?

    Most of the SPIFFS functions are called using SPIFFS, if I were to implement File functions, it would be easy for me to do, example:
    Teensy end runs:
    SPIFFS.close() ;
    ESP end runs:
    f.close();

    does this sound good? (it makes sense to me but i like inputs)

    note, i will incorporate SPIFFS as well for remote teensies, which will allow teeensy to read/write a remote teensie’s SPIFFS filesystem for remote management over MQTT
    It might be good for remote logging over MQTT as well. i however dont think controlling the EPROM of the ESP’s will be a good idea since it’s being used for configuration purposes, at least SPIFFS has random access and tons of space to work with.

    dropping the local File class on the protocol might be a good decision, and just incorporate the functions in the library while the ESP does all the File class work on it’s end, maybe by the weekend i’ll try to finish up the SPIFFS functions on teensy end and upload a video with an example snippet i found online for writing 10 entries and reading them back, at minimum the functions in that code will be added first before i work on implementing the rest of the functions used by SPIFFS to make sure things will work okay on teensy end

    Tony
    Last edited by tonton81; 01-10-2018 at 01:50 PM.

  14. #14
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    sorry for the delays, 35cm snowfall ruined my online/programming weekend

    I implemented quite a few SPIFFS functions over to teensy end, and am successfully able to read file contents on the teensy end including payload read(buf,len) support as well.

    SPIFFS.begin,read,peek,available,read(payload),see k,format,open,exists,rename,remove,position,size,n ame,close

    i still need to work on adding the directory methods as well as write function, which didnt have time to do so as of yet, but the above functions are working as of now, tomorrow is another day to work on more method communications

  15. #15
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    and can dump the whole file into teensy monitor as well:

    Code:
    bool f = SPIFFS.open(“/f.txt”,”r”));
    if ( f ) {
    uint8_t buf[SPIFFS.available()];
    SPIFFS.read(buf,sizeof(buf));
    for ( int i = 0; i < sizeof(buf); i++ ) Serial.print(buf[i]);
    Serial.println();
    SPIFFS.close();
    }
    Or:

    Code:
    bool f = SPIFFS.open(“/f.txt”,”r”));
    if ( f ) {
    for ( int i = 0; i < SPIFFS.available(); i++ ) Serial.print(SPIFFS.read());
    Serial.println();
    SPIFFS.close();
    }
    first method is more efficient, 2 serial transactions for a full file, whereas second one is less efficient, 190 byte file is like 380 uart transactions (out request byte, in capture byte)

    380 vs 2 transactions
    payloads win

    Tony
    Last edited by tonton81; 01-15-2018 at 06:15 AM.

  16. #16
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    wow! 23+ methods for SPIFFS, finally completed porting over the FS.h through transparency, including FSInfo!

    Code:
        FSInfo fsInfo;
        SPIFFS.info(fsInfo);
        Serial.print("Filesystem: "); Serial.print(fsInfo.usedBytes); Serial.print(" / "); Serial.println(fsInfo.totalBytes);
    result:
    Code:
    Filesystem: 502 / 957314
    To simplify things, the File and Dir classes are 'forwarded' by the object and ran remotely, so instead of running:
    Code:
       Serial.println(dir.openDir("/"));
        Serial.println(dir.next());
        Serial.println(dir.fileName());
        Serial.println(dir.fileSize());
        Serial.println(dir.openFile("r"));
    Simply do:
    Code:
      Serial.println(SPIFFS.openDir("/"));
        Serial.println(SPIFFS.next());
        Serial.println(SPIFFS.fileName());
        Serial.println(SPIFFS.fileSize());
        Serial.println(SPIFFS.openFile("r"));
    heres a working example of writing a payload to a file on SPIFFS from teensy:
    Code:
        Serial.println(SPIFFS.open("/f.txt", "w")); // returns true when file is open for writing
        uint8_t moo[] = "hello tweety bird!"; // setup a buffer for the message
        Serial.println(SPIFFS.write(moo, sizeof(moo))); // returns count of bytes successfully written
        SPIFFS.close(); // closes the file when done.
    AFAIK local spiffs support is now done on teensy end, i still need to get back on the mqtt code as well, for teensy controllers as well as remote SPIFFS management

  17. #17
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    New addition, transparency for async mqtt methods AND callbacks!
    How is this for the simulation?

    Constructor:
    Code:
    teensquitto mqtt = teensquitto("MQTT", &Serial1);
    Methods ported to teensy:
    Code:
      bool connected() const;
      void connect();
      void disconnect(bool force = false);
      uint16_t subscribe(const char* topic, uint8_t qos);
      uint16_t unsubscribe(const char* topic);
      uint16_t publish(const char* topic, uint8_t qos, bool retain, const char* payload = nullptr, size_t length = 0, bool dup = false, uint16_t message_id = 0);
    Welcome to the transparent handler!
    Code:
      mqtt.onConnect(onMqttConnect);
      mqtt.onDisconnect(onMqttDisconnect);
      mqtt.onSubscribe(onMqttSubscribe);
      mqtt.onUnsubscribe(onMqttUnsubscribe);
      mqtt.onMessage(onMqttMessage);
      mqtt.onPublish(onMqttPublish);
    as you can see, the handlers are the same as the original ASYNC MQTT library by marvin:
    Code:
    void onMqttConnect(bool sessionPresent) {
      Serial.println("CONNECTED");
    }
    void onMqttDisconnect(AsyncMqttClientDisconnectReason reason) {
      Serial.println("DISCONNECTED");
    }
    void onMqttSubscribe(uint16_t packetId, uint8_t qos) {
      Serial.print("SUBSCRIBED: ");
      Serial.print(packetId);
      Serial.print("  qos: ");
      Serial.println(qos);
    }
    void onMqttUnsubscribe(uint16_t packetId) {
      Serial.print("UNSUBSCRIBED: "); Serial.println(packetId);
    }
    void onMqttMessage(char* topic, char* payload, AsyncMqttClientMessageProperties properties, size_t len, size_t index, size_t total) {
      Serial.println("Publish received.");
      Serial.print(" topic: ");
      Serial.println(topic);
      Serial.print(" payload: ");
      for ( int i = 0; i < len; i++ ) {
        Serial.print(payload[i], DEC); Serial.print(" ");
      } Serial.println();
      Serial.print(" qos: ");
      Serial.println(properties.qos);
      Serial.print(" dup: ");
      Serial.println(properties.dup);
      Serial.print(" retain: ");
      Serial.println(properties.retain);
      Serial.print(" len: ");
      Serial.println(len);
      Serial.print(" index: ");
      Serial.println(index);
      Serial.print(" total: ");
      Serial.println(total);
    }
    void onMqttPublish(uint16_t packetId) {
      Serial.print("PUBLISHED: "); Serial.println(packetId);
    }
    Here's some random output from random subbing/pubbing/unsubbing/connect etc
    Code:
    Publish received.
     topic: teensquitto/35:43:3A:43:46:3A/amber
     payload: 52 53 54 55 56 4 61 0 
     qos: 2
     dup: 0
     retain: 0
     len: 8
     index: 0
     total: 8
    
    UNSUBSCRIBED: 484
    
    PUBLISHED: 485
    
    PUBLISHED: 486
    
    ESP was reset.
    
    CONNECTED
    
    SUBSCRIBED: 1  qos: 2
    
    PUBLISHED: 2
    
    PUBLISHED: 3
    
    Publish received.
     topic: teensquitto/35:43:3A:43:46:3A/amber
     payload: 52 53 54 55 56 0 0 0 
     qos: 2
     dup: 0
     retain: 0
     len: 8
     index: 0
     total: 8
    ill try to add the ESP handlers as well (connect/disconnect/etc) but away from pc now

    Tony
    Last edited by tonton81; 01-17-2018 at 01:19 AM.

  18. #18
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    Silly me, forgot to add remaining methods from marvin's mqtt

    Code:
        virtual bool setKeepAlive(uint16_t keepAlive); // MQTT
        virtual bool setClientId(const char* clientId); // MQTT
        virtual bool setCleanSession(bool cleanSession); // MQTT
        virtual bool setMaxTopicLength(uint16_t maxTopicLength); // MQTT
        virtual bool setCredentials(const char* username, const char* password = nullptr); // MQTT
        virtual bool setWill(const char* topic, uint8_t qos, bool retain, const char* payload = nullptr, size_t length = 0); // MQTT
        virtual bool setServer(IPAddress ip, uint16_t port); // MQTT
        virtual bool setServer(const char* host, uint16_t port); // MQTT
    teensy should have full access to mqtt now, ill start working on the WiFi handler next
    Tony

  19. #19
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    Today I finally finished the WiFi handlers (all 8 of them!) including their events have been driven for true transparency!
    Here's the 8 handlers from ESP thats emulated on teensy.

    Code:
            WiFiEventHandler onStationModeConnected(std::function<void(const WiFiEventStationModeConnected&)>);
            WiFiEventHandler onStationModeDisconnected(std::function<void(const WiFiEventStationModeDisconnected&)>);
            WiFiEventHandler onStationModeAuthModeChanged(std::function<void(const WiFiEventStationModeAuthModeChanged&)>);
            WiFiEventHandler onStationModeGotIP(std::function<void(const WiFiEventStationModeGotIP&)>);
            WiFiEventHandler onStationModeDHCPTimeout(std::function<void(void)>);
            WiFiEventHandler onSoftAPModeStationConnected(std::function<void(const WiFiEventSoftAPModeStationConnected&)>);
            WiFiEventHandler onSoftAPModeStationDisconnected(std::function<void(const WiFiEventSoftAPModeStationDisconnected&)>);
            WiFiEventHandler onSoftAPModeProbeRequestReceived(std::function<void(const WiFiEventSoftAPModeProbeRequestReceived&)>);
    just like the ESP end, initializing the handlers are the same.

    ESP EXAMPLE:

    Code:
      onStationModeGotIPHandler = WiFi.onStationModeGotIP(onStationModeGotIPCB);
      onStationModeDisconnectedHandler = WiFi.onStationModeDisconnected(onStationModeDisconnectedCB);
      onStationModeConnectedHandler = WiFi.onStationModeConnected(onStationModeConnectedCB);
      onStationModeAuthModeChangedHandler = WiFi.onStationModeAuthModeChanged(onStationModeAuthModeChangedCB);
      onStationModeDHCPTimeoutHandler = WiFi.onStationModeDHCPTimeout(onStationModeDHCPTimeoutHandlerCB);
      onSoftAPModeStationConnectedHandler = WiFi.onSoftAPModeStationConnected(onSoftAPModeStationConnectedCB);
      onSoftAPModeStationDisconnectedHandler = WiFi.onSoftAPModeStationDisconnected(onSoftAPModeStationDisconnectedCB);
      onSoftAPModeProbeRequestReceivedHandler = WiFi.onSoftAPModeProbeRequestReceived(onSoftAPModeProbeRequestReceivedCB);
    TEENSY EXAMPLE:

    Code:
      WiFi.onStationModeGotIP(onStationModeGotIPCB);
      WiFi.onStationModeDisconnected(onStationModeDisconnectedCB);
      WiFi.onStationModeConnected(onStationModeConnectedCB);
      WiFi.onStationModeAuthModeChanged(onStationModeAuthModeChangedCB);
      WiFi.onStationModeDHCPTimeout(onStationModeDHCPTimeoutHandlerCB);
      WiFi.onSoftAPModeStationConnected(onSoftAPModeStationConnectedCB);
      WiFi.onSoftAPModeStationDisconnected(onSoftAPModeStationDisconnectedCB);
      WiFi.onSoftAPModeProbeRequestReceived(onSoftAPModeProbeRequestReceivedCB);
    notice the difference? thats how it will be done on teensy end.

    As for the callbacks themself, they are all identical on both ends, so for teensy you could just do:

    Code:
    void setup() {
      WiFi.onStationModeGotIP(gotIP);
    }
    
    void gotIP(const WiFiEventStationModeGotIP& event) {
      Serial.println(event.ip);
      Serial.println(event.gw);
      Serial.println(event.mask);
    }
    now that Teensy has all callbacks for ESP core and MQTT, this could faciliate libraries working on teensy without putting any code on the ESP end.
    Ex. whatever you had in your ESP loop can be ran same as on teensy:

    Teensy example:

    Code:
    void loop(void){
        if (WiFi.status() != WL_CONNECTED)
        {
          digitalWrite(2,1);
          WIFI_Connect();
        } else {
          digitalWrite(2,0);
        }
    ...
    ...
    }
    I'd also like to mention teensy has a benefit over the ESP here, introducing delays() into the callback will NOT crash the ESP, as the data was streamed to the callback interface, ESP is doing it's own thing non-blocking even if you put delays all over your callbacks! This is same even for the MQTT handlers!

    Tony
    Last edited by tonton81; Yesterday at 08:15 PM. Reason: info on delaying callbacks

  20. #20
    Senior Member
    Join Date
    Dec 2014
    Posts
    285
    This is very powerful - remarkably transparent. An excellent way of easily adding MQTT to teensy! Congratulations

    Forgive me if I've skipped past it somewhere, but do you have this up on GitHub or similar anywhere?

  21. #21
    Senior Member
    Join Date
    Dec 2016
    Location
    Canada
    Posts
    837
    not yet its a WIP, im redoing all the H files from ESP currently, almost done porting esp8266wifista.h to teensy end for emulation, teensy will have truely amazing non-blocking callbacks with ESP functions integrated. i need to add 4 more bool functions from the H file STA to have the entire file emulaed. then i will work on porting the rest (wificlient, udp, and the ESP object itself (ESP.reset, etc).

    good news is updating the core will not break the code as they pass the original methods, and core libraries were not hacked in any way during the process. i recently changed esp core from 2.3 —> 2.4 and will all the patches they did it didnt break anything, literally you would need to change the function’s overload to break the emulation link, and if they did that, people who use those functions on ESP would have broken sketches, so transparency is not affected during library/core updates, it will work always

    whats done so far is:

    ESP8266Generic.h —> all 8 handlers including event data is ported to teensy, with non blocking callbacks
    ESP8266WiFiSTA.h —> every single function except the last 4 bool ones are complete, i will add the rest today
    SPIFFS —> all file and spiffs header functions are included, for true emulation locally on teensy
    ^— treat it as if teensy has its own flash system, as per previous posts:
    Code:
    bool f = SPIFFS.open(“/f.txt”,”r”));
    if ( f ) {
    for ( int i = 0; i < SPIFFS.available(); i++ ) Serial.print(SPIFFS.read());
    Serial.println();
    SPIFFS.close();
    }
    async mqtt library by marvin: https://github.com/marvinroger/async-mqtt-client
    ^—all callbacks (and non blocking too!) and all functions emulated on teensy

    like i said i will bring over the majority of the esp core functions to teensy end so people will be easily able to access the wifi network with it using ESP like calls:

    client.read()
    WiFi.begin(“tonton”,””myPass”,11); <— i dont only follow the functions, but also the overloads. if you want to connect using the BSSID from teensy, go ahead, its all functional!
    if ( WiFi.status() != WL_CONNECTED ) { <— yes this works too

    if popularity arises, i could add other libraries as well (ex PubSubClient). the reason i went for martins mqtt library is it supports all QOS levels for a project i was going to work on before creating this teensy/esp symbolic link protocol.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •