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:
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.
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:
and the current constructor for the server:
current constructor to enable ESP8266WiFiSTA.h transparency:
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
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