PHGMS log

A first version is working. It uses a Feather ESP8266, which reads the reed switch and posts changes to a MQTT topic on the Sinology. A node app subscribes to that MQTT topic, and serves a webpage to which to re-sends the MQTT events over websockets. The webpage registers the websocket messages and uses them to update the knockout viewmodel. The viewmodel sets CSS classes to show the current state of the reed switch.

This works because I use technologies I previously learned. However, I’d like to change some things which require new skills:

First, I would like to change the wifi radio with a NRF24l01 radio, since these can be made less power-hungry. This could enable the garage sensor to be battery-powered. This means that the receiver would have to be a Raspberry Pi, since the NRF chip needs an SPI interface to be read. The RF24 library by ManicBug has a python-wrapper, so this should be feasible.

To get the RF24 lib working on Raspberry Pi:

  • To compile the python lib, the swap file needs to be increased (I did 1000mb)
  • When combining the rf24 lib with MQTT, a segmentation fault occurred. This was solved by running the python script as root.

Currently, communication over the RF24 is working, and a python script which converts radio messages to MQTT events is running. These are hacked together, and should be reworked.

Second, I’m trying to get MQTT working in the browser using webpack. This would simplify the overall design, since I would no longer need a node app, or websockets. I must admit, webpack seems very strange to me…

  • using require(‘mqtt’) did not seem to work
  • building mqtt according to the instructions on the npm page yielded several errors, which could be remedied manually.
  • as the URL, the format of ‘ws://<ip>:9001’ needed to be used. Websockets should be enabled in the mosquitto.conf file.

Currently, it works, but a built browserMqtt.js file is loaded using a script tag. I’d rather have mqtt as a module, which is included by webpack during a build.

Next steps: require(‘knockout’) and webpack that shit!

  • Update 08/05/2016: using knockout with webpack was easier than expected, and worked right out of the box.

Perhaps it is just the mqtt library which is a bit wonky with webpack, and not webpack itself? Let’s hope so… Currently, it does not seem worth it to focus on mqtt/webpack much longer, I’ll just leave it be and use the ugly way (first, load browserMqtt.js, then bundle.js in script tags).

Next step: porting the existing UI (which worked through websockets) to a webpacked version.

  • Update 08/05/2016: no surprises, the webpacked version works fine. Possibly, the Pluralsight course can be explored further to see if css and fonts can be included as well. Moreover, a server for the files should be created. Probably best to do on the Sinology, since it can already host node apps?
PHGMS log

ESPbot-constructie krijgt vorm

De constructie van de ESP-bot begint ondertussen zodanig vorm te krijgen dat er aan de functionele kant gedacht kan worden!

Uiteindelijk ben ik gegaan voor 2 micro-processors: een ESP8266 en een Arduino Pro Mini. Uiteraard probeer ik de taken van beiden mooi gescheiden en duidelijk omschrijfbaar te houden. Vandaar deze poging:

De ESP zorgt voor het verzamelen en aanreiken van data en het opvolgen van user input. Algemeen gezien zijn dit dus input-taken uit de omgeving. De ESP moet zelf geen data opvragen bij webapps, maar krijgt alles via MQTT messages. Qua knoppen zijn er 2 pushbuttons en 1 potentiometer voorzien.

De Arduino verzorgt de output. Hiervoor heeft hij:

  • 5 NeoPixels: 2 in de ogen, die vooral gebruikt worden als data-displays (bvb., is het nog geen tijd om te gaan lopen?), en 3 in zijn rechterarm, die waarschijnlijk vooral voor grafische effecten gebruikt gaan worden.
  • Een TFT-display als “tekstballon”, om context te geven aan het data-display, of andere onnozeliteiten.
  • Een buzzer.

Communicatie tussen de twee gebeurt via I2C. Berichten bestaan, net zoals de MQTT messages, uit een topic en een payload. Topics kunnen webapps zijn (zoals runmonitor), of rechtstreekse commands van de ESP naar de Arduino toe (CMDNEO of CMDSCR) op basis van de user input.

De ESP moet dus niets weten van de staat van de output: hij vuurt input-events (data of knoppen) af naar de Arduino, die (in geval van data) de gegevens opslaat, of reageert op de input-events. De Arduino kent dus niets van MQTT.

Te doen: code opkuisen! Momenteel lag de focus vooral op het doen werken van de verschillende onderdelen, maar om geavanceerde functionaliteit toe te kunnen voegen zal het makkelijker zijn om verschillende dingen in aparte klassen onder te brengen.

Daarnaast: Adafruit heeft aangekondigd om in hun display-libraries verschillende fonts nu te voorzien. Moet eens bekeken worden!

En ook nog: de webapps moeten aangepast worden zodat er korte tekst of kleur-informatie opgevraagd kan worden.

ESPbot-constructie krijgt vorm

ESPbot groeit gestaag

… maar wel met rasse schreden! Ondertussen is de hardware geprepareerd (robot in kader, neopixels en scherm geplaatst), en begint de software-architectuur vorm te krijgen.

MQTT leek me het beste om mee te werken qua messaging. Bij het aanspreken van verschillende REST-services had ik namelijk al wat problemen (prutsen met timeouts enzo), maar de MQTT library voor de ESP werkte dadelijk mee. Makkelijker en uitbreidbaarder, yessir! De ESP moet dus geen REST meer uitvoeren, enkel publishen en subscriben naar MQTT. Daarvoor moest echter eerst nog een MQTT server worden opgezet, en een MQTT<->REST vertaler gemaakt worden.

De MQTT server was al geen probleem: op de Synology kan een package geïnstalleerd worden die vanaf dan alles regelt. EZ! De vertaler was ook verbazingwekkend makkelijk, vooral door (weeral) de goede library beschikbaar voor Node.js.

Momenteel moet de ESPbot maar een berichtje “all” in de request-topic van de MQTT server posten, om de MQTT<->REST vertaler in gang te steken. Die haalt de data bij alle services op, en post deze in de geschikte topics op de MQTT server. Vandaar kan de ESPbot zelf beslissen wat hij met deze data doet. Dat is momenteel in ontwikkeling. Stay tuned!

ESPbot groeit gestaag

ESPBOT met TFT?

Na een avond prutsen is het gelukt om een TFT van Adafruit werkende te krijgen op de ESP8266. Dit opent natuurlijk verschillende mogelijkheden!

Om verschillende types informatie te laten zien, wordt het misschien wel makkelijker om MQTT te gebruiken.

Ik neig er ook naar om de neopixels een aparte arduino te geven. Er kunnen hele mooie effecten mee gemaakt worden, maar die vereisen volgens mij wel dat er weinig delays gebruikt worden. De ESP8266 zou dan via het zetten van bepaalde pins een modus op de arduino kunnen bepalen. Stof om over te denken!

ESPBOT met TFT?

ESPBot

Een mooie front-end robot, met daarachter een ESP8266 die van verschillende bronnen data binnentrekt en deze via Neopixels laat zien. Mogelijke data-bronnen: runMonitor, afstandsmeter, en getWorkDry (variant van getHomeDry).

De ESP8266 lijkt een grillige chip te zijn. Hoewel hij op 3.3V werkt, reboot hij telkens als ik de 3.3 FTDI gebruik. Bij gebruik van de 5V FTDI is er geen probleem. Adafruit leverde gelukkig een voltage regulator bij op het bord!

ESPBot