Search results for:

This is how I'd approach it, at a high level.

Since I'm unsure how the Pucks' signal would fare over the distances and through walls I'd suggest each of the four rooms has Puck button and a Raspberry Pi Zero W acting as a receiver. Pucks could be carried in a similar fashion to your remotes around and between rooms.

Each Pi Zero W could listen on BLE for the Puck associated with its room, or probably better, to all Pucks to ensure good coverage. Pi Zero W boards are all connected via LAN.

Puck button events are relayed to Pi Zero W. A received confirmation could be sent back over to the puck over the same service. - probably UART would suffice to simply light up the LED. The Pi Zero W relay events over MQTT (or similar), to a server application on one of the Pi Zeros (primary) attached to a display running a web or console based UI there.

Second display probably runs another Pi Zero W as a slave and listens for update signals from primary to update it's own web or console based UI. Websockets will do here.

There's a starter for ten. Maybe others can finesse the approach.

Too early to ask about pricing/spec on the barebones boards?

Ah thanks, so in that case, that won't help. Looks like OP is passing true for alwaysExec already. So @user87803 it looks like it will persist beyond reset() but not reset(true) which is going to empty the flash.

'E.setBootCode' underpins the Espruino save on send functionality from the IDE, and that has an option to persist/run after reset. I guess there's an argument you can pass, but if not maybe you can use the IDE.

I noticed when testing similar code that the first reading after offsetting with zero = Puck.mag(); gives x, y and z values close to zero, as you'd expect, but second and subsequent jump to values that vary (+/-) quite a bit from zero, and actually found it better to do use a later reading as a zero/offset, making a couple of calibration passes as below

var offset = {x:0, y:0, z:0};
var calPass = 2;

function readMag(mag){
  if (calPass > 0) {
    // calibration pass
    offset.x = mag.x;
    offset.y = mag.y;
    offset.z = mag.z;
    calPass--;
  } else { 
    // provide reading
    mag.x -= offset.x;
    mag.y -= offset.y;
    mag.z -= offset.z;
    console.log(mag);
  }
}

Puck.on('mag', readMag);
Puck.magOn();

I doubt it matters much, as slight changes in orientation of Puck still move values considerably, regardless, but it seems the Puck.mag() reading doesn't quite do the zeroing/reset I expected.

@user87799 headers won't be a problem, I don't think, but ESP8266 on the NodeMCU is not capable of HTTPS communication via Espruino, so unless Adafruit offer the http:// schema on their API you'll need use a Pico or Espruino Wifi (or maybe ESP32 - I'm not too familiar).

I tried to talk to Espressif at embedded world - maybe I talked to the wrong people, but they honestly couldn't care less about Espruino

Shortsighted of them Gordon. They are missing a trick.

I'll look into reading the RSSI both ways - that's a great idea - thanks

Hi Gordon. I have five boards, but at moment I'm only using one - nothing fancy just attempting to get some correlation between distance and RSSI signal emitted by the puck. I saw this as the first step, without some form of calibration, reliable triangulation would be hard to achieve?

I've also read of indoor location tracking being done using magnetic fields. Could the puck's magnetometers be up to this when used in an array - maybe if the person carried a magnet?

Hi, was any progress made on this? I'm trying to do something along the lines of @Gordon's first example - Pi Zero W boards detecting Pucks.

In theory this is totally doable, but I seem to have so many issues with RSSI readings that I'm not sure it can be used with any confidence. Readings seem to depend on Puck orientation, contain frequent spurious results and if the Puck is on someone's person, and in different places, the RSSI readings are different again. There seem to be many factors which can impact the RSSI which gets read.

Would love to know if you got somewhere with your project and to hear from anyone else who has had some success with proximity/location tracking?

@opichals you could wrap that in a bash file and pass in flags, no? I use a small Go utility for ESP8266 which does exactly this - and returns IP address so subsequently can connect via IDE over Telnet

Here is snippet that may help. You could use port 80 if wished.

var server = require('ws').createServer(servePage);

  server.listen(8000);
  server.on("websocket", function(ws) {
    ws.on('message', function(evt){
    // handle the message
    });
  });

```

Mine run from Mac USB power. These and the NodeMCU have always been pretty reliable on USB power. Only when I've been using the 01 and 12 directly have I needed to use a capacitor and maybe supply power from a source other than the USB FTDI adapter. Are yours genuine D1s? You don't think you could have got a bad batch? The quality varies with the cheap boards and I've bought ESP8266 boards that don't do what they should before now (Wifi Node-M).

I use the D1 Mini - well I think they're clones. I'm behind on versions but I flashed 1.91 recently and could connect via Espruino IDE no issues. Have you tried an older version out of interest?

Edit: espruino_1v95.4819_esp8266.tgz works fine. I didn't set 4M-C1 I used 32m in the esptool command as normal. Not sure what that's for? Otherwise flash command is same including 115200 baud, but not port I'm on Mac.

When started with these I needed a different serial driver (wchusbserial1410) it took a bit of finding. I wonder if that's relevant? Though if you've flashed it ok I'd guess not.

@tempos It is possible. Many have run it on bare boards even the ESP 8226-01.

It is a while since I have used on ESP8226 (certainly I've not tried any >1.9 binaries) so can't offer much constructive help.

But, things to try if you have not already:-

1) Run "erase_flash" first. This always seemed to help get a clean flash of the binaries.
2) Wiring. A couple of gotchas for me: "CH_PD" needs to be pulled high (3.3v) and GPIO 0 needs to be high for normal use but pulled low (GND) for the purpose of flashing. Also your need that capacitor you say you will try. Otherwise the power to the board from your FTDI style adapter just is not stable enough. These are a couple of annoyances you don't need to consider with Node MCU.

You may have all this hand, but if not hope it helps.

Thanks @opichals I'd come to that conclusion re the SDK.

Re use-case - honestly? It started out as a learning exercise, but I've found it to be very useful and reliable. Re performance, I don't have any benchmarks, my apps are sending at 50ms intervals with no problems, but I appreciate that's not particularly fast when compared to MQTT QoS 0 which I think is the best comparison. That's not to say the interval can't be much smaller. I haven't tried.

I could run Mosquitto locally, and may end up doing, but this has fewer moving parts to achieve (or at least emulate) the same thing. That was the attraction really.

I'll look into CoAP though since I've no experience with that. Thanks again.

From what I've gathered frames are lower level than UDP. And yes it's nothing like real pub/sub, the client basically filters the frames based on a list of subscriptions it holds in memory and discards everything else.

Just checked out that module - I wouldn't have the first idea what to do with that :) so I think I'll look further at your suggestion on UDP. Thanks @Gordon.

Could network enabled Espruino devices communicate using Ethernet frames?

I ask as I've been using some MQTT style code written atop a Go Ethernet Frames library on Raspberry Pi. The broadcast option means you can achieve something very like MQTT pub/sub, but without data ever leaving your network and/or the need for a broker to relay via ( I always rely on the free insecure ones)

It's worked well on a couple of projects I've done, so, I'm now wondering could I get Raspberry Pi talking to Espruino over same protocol?

So nobody learned anything at NodeConf - too busy playing with their badges? I would have been. Very nice.

@Polypod suspect your circuit isn't reversed just the metal case is rotated 180 degrees

@Gordon No, I've had no issues, but admittedly this binary only serves a RC car controller webpage and the websocket connection. I'm not using it anywhere else, but it works like a charm for that. Maybe not enough evidence to change it :)

@PressAnyKey, there's a port in progress. @Wilberforce and @JumJum are leading it. You can also get them on the gitter channel here https://gitter.im/espruino/esp32

I expect, you'll have no issues there - that's where I went after the Wifi-NodeM. Specifically I wanted an unpinned board, and they've been great.

Re space - I think a part of it is that the port was designed to accommodate the entire ESP8266 family, including the ESP8266-01. You can use that flash, but as a key/val store. save() doesn't use it all.

Re the module, and subscribe reconnection. It's been a while since I've used, but I seem to think subscriptions resume or at least aren't cancelled by the disconnection, but don't hold me to that. Please feedback how you get on.

BTW the Espruino Gitter channel might be useful. There are people in there who know more about the ESP8266 port than I, so could advise what might be possible on the space front, there's also one user of ESP8266/tinyMQTT who's been managing his home with it for 12 months, so he'd be a good person to pick up with.

@Scargill. Hello there! How are you approaching it? Generally, I put a call to connect in the disconnect event handler. Which module are you using? Myself and others have had good success with this cut down module (https://github.com/olliephillips/tinyMQTT).

So something like this:

mqtt.on("disconnected", function(){
	console.log("disconnected");
	mqtt.connect();
});

At the time of the espruino to ESP8266 port, there wasn't the room for the full MQTT module, though we now have 1700 jsvars I think some have squeezed it in, but can't save much application code.