-
-
The ESP32 will serve data directly from it's own IP - that's why it needs a separate network. If it was just making outgoing connections, I could use the real network.
I was totally overwhelmed by the amount of learning that would be required to figure out how to store the data on drazzy.com, and I talked to multiple friends who are experienced with setting up database servers, but they all told me different things, so I just threw my hands up in the air and decided to put the logic on the ESP32 because I know how to do that approach, and it's fun to write javascript, but unpleasant to try to figure out how to set up a database server - and then there's security, since I am not qualified to assess whether the database server is secure, I would need to have it isolated on another system, not drazzy.com, or find and hire someone who could assess it as such.
These are all shitty reasons, but I had literally spent over a year with multiple projects blocked because I wasn't able to make any progress without being overwhelmed by options, doubt, and confusion. So I was like - I need to actually do this, and stop letting the obsession with the "right way" prevent me from ever making progress, and use the techniques I know to make a working solution.
I already have the RF code written, so I'm not going to switch to the NRF or EFM boards. I am super busy and struggling to find time to work on projects as is. I have working RF code for arduino and can make a serial<->RF bridge for $3 by plugging an off the shelf receiver and/or transmitter into an off the shelf pro mini and uploading a sketch I've already written to it. Reinventing the wheel is a non-starter - especially since I have over a dozen devices already deployed and in use based on my current method.
Flash filesystem is a possibility - but if I'm actually writing it permanently, I might as well use an SD card so I can easily get the data onto a computer en masse.
-
One of my current projects is to get the data from the sensors in my room and make it available over the internet. A cloud provider that I do not control is out of the question, because those services can be shut down at the whim of a third party, but I don't want an Espruino (or anything) exposed to the internet on my real home network.
My plan is thus:
Second router, second wifi network for IoT devices we don't fully trust the security of.
ESP32 on that network, which will serve up json containing data from the sensors
Arduino Pro Mini (8mhz 3.3v) connected to the ESP32's UART2. This will use a 433mhz RF receiver (RXB-14 or RXB-12) and output the received data over serial to the ESP32.
Sensors will broadcast current readings on 433mhz RF.
Since E.setSNTP() doesn't exist on ESP32, will get current time from my webserver on AWS ( drazzy.com/time.shtml ) and use that to set it's internal clock.ESP32 will thus be able to serve up the current status of my room, as well as data to generate a graph of the past few days. The client pages will be served up from drazzy.com (or could be served from spencekonde.com - since it's personal stuff - or even located on local machine) and will use standard libraries to generate the graphs from it.
The same can also be done in reverse, with the ESP32 telling the Arduino to transmit commands based on received requests - the 433mhz is the "bridge" between the real home network, and the IOT-device one.
The next steps are to do the code that will store and serve the information on the ESP32, and finish the build of the new sensor and control hub that will live on the "real" side of the network.
Likely I will use an ESP32 board with the PSRAM once those are supported for JSVars in order to have more memory to store historical data, so the charts are richer. I'm unsure what, if anything, I'll do for permanent storage. Maybe FRAM. Maybe a uSD card... FRAM prices are way down lately, btw - 1mbit chips for under $7 now!
For the sensor controller (the one on the "real" network) I need to get an Espruino build environment set up for STM32 boards and make a copy of the Espruino Board definition, only for the D-spec part. I think I'll start a new thread about that.
-
-
-
So a build that would be like the bigram builds I used to do (at some point, the toolchain stopped working, and then I was forced to rebuild the system by amazon and forgot how to set it up anyway), only it would auto-detect whether that RAM was actually there? That would be really cool
An esp32 build that had 64K jsvars would be pretty cool. Would finally be hard to run out of ram on espruino.
-
-
-
Interesting that they vanished - I got one too before they disappeared.
A nearly identical board is available - but it has the parts mounted directly on it, and no nice metal shield:
https://www.ebay.com/itm/TTGO-T8-V1-1-ESP32-4MB-PSRAM-TF-CARD-3D-ANTENNA-WiFi-bluetooth/152817184015That listing is the one I bought from that got me the one with the WROVER module on it.
-
-
I just thought I'd let people know about an issue I'd run into:
With DIO, code executes somewhere in the neighborhood of 30-50% slower (I haven't timed it precisely) vs QIO. And you can't really tell if the board you bought has it wired as QIO or DIO until you try to flash it (the QIO capable ESP12 modules have "QIO" printed on the underside, but you can't see that if they're soldered in).
For my pingpong light controllers, I realized this after I had a bunch made with DIO modules (they have to all run at the same speed, and I'd like the QIO ones to run faster), so I've been taking the DIO modules off of my WeMos D1 Mini's with a torch and soldering a QIO one in it's place....
-
-
Until recently, I wasn't aware of "thermal wire strippers". These are devices which heat up an element that is then used to melt through the insulation of the wire, allowing you to easily strip it.
I had never realized how miraculously effective they are, nor had my father who built stuff since high school (he was etching PCBs at home in the 50s) and was an electrical engineer for his whole career. Holy shit. They are amazing. Before this, the most time consuming part of wiring up a project was often not the soldering, but just stripping the ends of the short little pieces of wire (shorter wire being harder to strip, because there's less wire to grab and pull).
The thermal stripper does it EFFORTLESSLY. You put it in, twist, gently pull, and off the insulation comes. The one I have doesn't get hot enough to burn you (well, I think the temperature is hot enough, but not enough thermal mass nor power output in the hot part) - the hot element is a little inch-long strip of metal with a slot in the middle, narrower at one end, so you put it in the wide end, slide to narrow end and twist 180 degrees.
It is magic, and I cannot recommend it more highly. The one I have is a PTS-10 from PATCO. I can leave it plugged in over night and it's fine the next day, no prob (just like my old vomit-green colored weller soldering irons) They're like $80 new, and worth every penny. I am in no way affiliated with nor compensated by PATCO - I just want to share this, because, well - because nobody ever told me about these, and I'd been stripping wires the hard way my whole life (well - almost my whole life, I wasn't doing anything with electronics until first or second grade IIRC). If I could go back in time and hand myself one 20 years ago, I totally would.
Has anyone else experienced the magic of these? Why are these such a well kept secret?
-
-
-
-
-
Does anyone know how i can read data from this sensor via Digital pin?
You cannot. The output is analog, not digital.
The analog input on the ESP8266 is pretty crap - but it does exist. Give that a try.
You could also use an external I2C or SPI ADC.
If you just care about it crossing a specific threshold, you could use a '393 to compare it with a reference voltage and drive a pin low when it's above (or below) that threshold.
-
-
-
You should be able to analogRead() on an ESP8266. There's only that one ADC pin, but last I checked reading from it worked fine.
You don't need to do pinMode(). Actually, with Espruino, you don't need pinMode() at all for doing basic GPIO - if pinMode() hasn't been called yet on the pin, digitalRead() will set it as input and digitalWrite() will set it as output. If pinMode() has been called already, it will leave it as is.
As an aside, you don't need to use pinMode() before analogRead in Arduino-land either, since pins start as inputs (at least for AVRs; I think same is true for ESP8266 though)
-
-
I've made some changes now for ESP8266 and software I2C that may fix this - but I'm working blind as I don't have an EEPROM on me to test with.
With this FW image:
http://www.espruino.com/binaries/travis/master/espruino_1v95.167_esp8266_4mb.tgzthe waveforms look better on the scope - but I still can't get it to work correctly, and now I don't really understand why. Same symptoms though. I can't figure out why it's not working - especially because, as I mentioned, it doesn't fail with the scope connected.
I'm not sure what's going on with the Software I2C. When using I2Ctouse=new I2C({scl:5,sda:4,bitrate:100000}); my scope refuses to trigger at all off of any I2C conditions. With the I2C triggering off, I don't see any signal going by at all when using software I2C...
-
It looks like there's a problem with servers not getting cleaned up when the board is reset (for example, when you click "send to Espruino" in the IDE):
First time I upload and try to fire up the server, it works. The second time:
It isn't clear to me yet exactly what the key factor is that makes this fail, but the code below readily reproduces it for me. Upload code once.
Request in browser:
(board IP address):7348/status?un=testuser&pw=testpass
Upload code again. Watch for error in console.
Powercycling the board fixes it.
Also, sometimes when I click send to Espruino, the following is printed to console:
Much thanks to everyone for all the work they've put into the ESP32 support.