Possibly. Getting data to the MQTT broker is pretty much the same as publishing to ThingSpeak; "This is my topic, this is its data". Simple as that.My first thought is something really simple. Can i not send mqtt commands as payload on an AT command to ESP01? Exactly as per the simple Thingspeak example (see my recent posting). Easy on a picaxe.
That's my inclination as well. A Pi or Linux PC is probably the best choice for implementing a local MQTT broker. Either can be used to get PC-based MQTT working locally, and both support Python and even MicroPython, both can interface to UART or AXE027.My suggestion would be to implement such an picaxe-mqtt interface device using MicroPython,
Which is the path I am going to walk. We'll see how it goes.Two weeks ago I set up a simple mqtt-network in my house using an old Raspberry Pi as a mqtt-broker, and am currently investigating options to show/visualize data ... on a phone or PC
Rather than a complete ThingSpeak server installed locally, a more lightweight server can act as a bridge which presents itself as ThingSpeak would but instead publishes to MQTT. That should only be a couple of dozen lines of code.where does this bit "a server which can take data provided as per ThingSpeak" come from? I could install Thingspeak, though it seems to be a mass of dependencies and non trivial. Do you have something else in mind?
I think the interest for IOT stuff on this forum is evident.The purpose of posting this is simply to see if there is any interest from others
Annex RDS already supports MQTT on ESP8266/ESP32. It can also certainly accept serial transmissions from a PICAXE. It can be flashed to an ESP-01, but I don't know what restrictions might apply to the limited flash and ram available on the ESP-01. https://sites.google.com/site/annexwifi/homecode and a reference design for the ESP-01, written in perhaps 'C'
But, let's be honest; that's mostly wanting Rev-Ed to do what people don't want to do themselves, would prefer not to have to figure out how to.I'm inclined to think Buzby is right about Rev-Ed having missed out on a good opportunity here.
#!/bin/usr/python2 import os; windows = os.name == "nt" import sys import serial import threading import time import paho.mqtt.client as mqtt uart_port = "/dev/ttyUSB0" uart_baud = "9600" mqtt_broker_ip = "127.0.0.1" mqtt_broker_port = "1883" mqtt_username = "pi" mqtt_password = "raspberry" mqtt_topic = "axenet" client = None comPort = None def on_connect(client, userdata, flags, rc): client.subscribe(mqtt_topic) def on_message(client, userdata, msg): comPort.write(str(msg.payload) + "\r\n") def UartReceiveThread(): s = "" while True: if comPort.inWaiting() > 0: c = comPort.read(1) if c == "\n" or c == "\r": if s != "": client.publish(mqtt_topic, s) s = "" else: s = s + c else: time.sleep(0.1) print("Bridge from " + uart_port + "," + uart_baud + ",N,8,1 to MQTT (" + mqtt_topic + ")") comPort = serial.Serial \ ( port = uart_port, baudrate = int(uart_baud), parity = serial.PARITY_NONE, bytesize = serial.EIGHTBITS, stopbits = serial.STOPBITS_ONE ) threading.Thread(target=UartReceiveThread).start() client = mqtt.Client() client.username_pw_set(mqtt_username, mqtt_password) client.on_connect = on_connect client.on_message = on_message client.connect(mqtt_broker_ip, int(mqtt_broker_port)) client.loop_forever()
See the last post of the "Where's the Wizard?" thread. Cut and pasted from ESP's doc.Are they abandoning NON_OS? The last version was 23 March this year.
Let's be really honest. If everyone figured out everything by themselves, they'd program PICs in assembler and Rev-Ed would have no customers.But, let's be honest; that's mostly wanting Rev-Ed to do what people don't want to do themselves, would prefer not to have to figure out how to.
That's not quite what I intended to say, and I don't think anyone else saw it like that either.