Search results for:

I am currently looking at the VCNL4200 module from @SergeP as promised. But without a VCNL4200 sensor at hand someone has to check the final version.
I can look into the module for the VL53L0X soon and i even have a sensor with that chip on the way as we speak.

Post the code here or in a github and i will have a look at it and modify it if necessary.

I think at the moment not.. but its really not easy to find solid information about the AT firmware and its capabilities. But i did find a statement that older versions are open source and therefore are extensible.. no idea how feasible that is though.
My only hope at this point is that you come up with some magic to make UDP multicast happen or espressif gifts us with a new AT firmware :)

This is a ES2015 feature and sadly not supported yet.

Hm.. maybe in newer versions of the AT firmware UDP multicast is properly supported too.
Is it possible to update the firmware without risking to kill the espruino?

Yes most of the modules have extensive documentation how to connect the hardware and example code. I edited my previous post with an example to further show the differences but you were to fast answering :D

Those Modules are software to drive/use the respective hardware modules.

For Example:
If i have a project in mind, let say a weatherstation, and i want to use a DHT11 to measure
the temperature. I connect the DHT11 sensor (hardware module) to my espruino. Then i need some software to "talk" to the sensor so i can read the temperature. This is where the espruino modules come into play. I require the library (software module) for the DHT11 and can easily connect and read temperature data from the sensor.

Even in a scenario where i do know the address of alexa it did not work. And if i understood the AT documentation right there is a mode (mode 2) in CIPSTART where you can answer to the message origin. And yes.. this is all just a lack of the AT firmware.

So i tried a few things now.. and sadly i am can't get alexa to discover. I tried starting the scan and then manualy responding to the UPNP search from alexa with multicast du 239.255.255.250:1900 but alexa does not care about it. I sniffed the traffic with tcpdump to make sure i send after the search from alexa and that my espruino wifi is sending the right response. While looking at the traffic running in with tcpdump i saw some devices answer to alexa directly and port of 50000 but still UDP. I tried that too.. but it it does not even show up in the tcpdump log. I guess with so much else i want to do i leave it as it is. Maybe i use a ESP8266 or ESP32 myself and round up the module but for espruino boards i see no chance without complete UDP support.

In my opinion you really can't compare hardware if you have to use different languages.
I know that you have no other choice and the code snippets are as close as they can be in the relevant parts. But you can not level out the differences the language itself brings to the table.

Right now the test is maybe telling more about the advantages of python then about the floating point capabilities of the underlying hardware.

I would have to try that.. but its a good idea. Other possibilities are maybe tcp broadcast in combination with a own skill thats using tcp broadcast for discovery or a solution with some kind of gateway and mqtt for example. But this is all far more work then necessary.. if espressif would just have included this feature in their AT firmware.. its in the SDK.. why not exposing it in the AT firmware grml

I did read its possible to modify the AT firmware and add features to it.. this would be another solution.. but maybe the hardest route to go.

Well.. if found a thread regarding UDP multicast with AT firmware http://bbs.espressif.com/viewtopic.php?f­=16&t=234&p=6382&hilit=multicast#p6382 .
The thread is a bit older but since i can't find anything thats stating the opposite it seems the AT firmware does not support this.

Thats it then.. or has someone another idea?

Oh my god.. with EspruinoWiFi it does work. Sorry i missed that!
By the way there is still the bug when i call getIP without connecting beforehand.. i fixed this in you posted beta version and i am quite sure i did a pull request a while back that fixed this. Seems like it found its way back :D

No right hand side as usual. If i require Wifi it works fine.

Edit

I tried your provided beta version of EspruinoWifi and the
CIPCIPSERVER Error is gone. Sadly UPnP packages still do not arrive.. but i am a step further and have to debug it.

Edit 2

I changed the code of the beta EspruinoWifi so the Dgram.createSocket results in calling the AT command AT+CIPSTART=0,"UDP","0",0,1900,2 which.. according to a guide i found should listen on port 1900 for incoming messages from all addresses and allow me to respond to the sender of the last incoming message with AT+CIPSEND. If i then a UDP message to 239.255.255.250:1900 with netcat no message arrives. If i send the UDP message directly to the IP of the espruino (192.168.0.17 in my case) the message arrives.

Does the AT firmware not support broadcast/multicast? Or what could be the problem?

@Gordon I did require "Wifi" because "EspruinoWifi" was not found with 1.95 but i did indeed forget about the new beta version from you here in this thread. As soon as i am home i give it a try and report back.

So i am back on this and i was surprised that with v1.95 i had to require Wifi instead of EspruinoWifi and no more errors because of missing Dgram module. But it still does not work for me.. its seems i cant receive alexas UPnP requests.

@Vasily Does this still work for you after updating to v1.95?

Edit

Okay.. after checking v1.95 change nodes, reading the updated references and making some changes i am few steps closer and could fix some bugs in code i never reached before.

Now i am stuck at an error from espruino "CIPSERVER failed" .. i guess it is the Dgram.createSocket but i have to check that after some sleep and try to reduce it a minimal snippet to reproduce.

Other odd thing.. Wifi.startAP seems to always want a password.. even with authMode "open". For now i did remove the AP parts.. don't know why they are needed anyways.. maybe you could shed some light on this @Vasily? :)

@Wilberforce Thanks for looking into this. I did find those documents too, but they are all for other sensors and in almost every document they come up with some magic device specific constants. Sadly the other sensor are quite different spec-wise so i can't work with those formulars and/or magic constants.

I could need some help writing a conversion function to lux for this sensor. Contrary to the other light sensors of this manufacturer they do not provide a formular in the datasheet to convert from sensor output in counts to lux. The different conversion functions i could find floating around in the internet are all derived from the adafruit code for this sensor. But according to multiple sources the results are not correct so i left that function out for the time being.

Since i do not really need a conversion to lux and i can not validate a against a luxmeter i put this work in progress code to the public. I hope someone is proficient in this area and can round off the code with this last missing piece.

You can find the source, examples and documentation in my github account here.

function func(_pin)
{
    if (_pin instanceof Pin)
    {
        /* here some code */
    }
}

Or.. if the contextObject you need is the outer scope just use a arrow function as setTimeout callback and be done with it.

Other public choices for the this alter ego are me and self :D

Maybe it is a timing issue and using a Promise could help.. dont know the complete code but something like this could work:

function getPrices() {
  return new Promise((resolve, reject) => {
    h.get(`${proxy}${api}${symbols[++symbolC­tr % (symbols.length + 1)]}-${currency}`, res => {
      let pricesRaw = "";
      res.on('data', d => pricesRaw += d);
      res.on('close', () => (prices[symbol] = JSON.parse(pricesRaw), true) && resolve());
    });
  });
}

And in your other code just do:

getPrices().then(showPrices);

Error handling ommited for keeping it simple.. but you should take care of it :)

I bought a cheap breakout for a temperature sensor and had no manual or other indication of which I2C address is used. So i wrote code to scan all I2C addresses and because it helped me i pimped it a little and made a ready to use module for everyone who might need it in the future.

You can grab the code, usage example and options documentation here.

@Wilberforce i think using the mac address is a better fit in this scenario and there are multiple ways to get a mac address then a serial. But to be portable i used the callback variation of getIP so we should be fine in this regard.

@Vasily nice to hear!! And to be clear... there is no bug in UDP its just not know supported for espruino devices.. so the alexa code right now just works for ESP8266 and maybe ESP32 users.

@Gordon thanks for the code.. had no time so far to look into it though.
@Vasily i saw that the getIP call is for getting the mac address and that it is only used to create an identifier.. but i think its a good idea so i left it in.

Only problem right now.. besides spare time to get into it.. is UDP or more specific multicast UDP.
In a short research i found inconsistent statements about support of the AT firmware for multicast UDP. I guess next step will be to whip up some dirty test code and see if alexa can find a device.

By the way there is a chance the rest of the code works as is.. at least for folks with a ESP8266.

I changed getIP occurrences already to the callback variation.. but in the EspruinoWifi module is a bug that prevented me to use getIP without beeing connected to just get the mac address. That is the fix i was talking about and i will make a pull request when i have looked more into possible side effects of my fix.

@Gordon Do you have a rough timeline when UDP support is done? Or would it be worth it to hack the few things i need for this together myself.. if at all feasible.