Most recent activity
-
Had something similar on one button. Pulled out a couple times, and it's OK again since...
-
You didn't specify what you already have, so I have to ask some questions. :)
OpenHAB can subscribe to MQTT, you have a lot of options.How big area you want to cover? Wall thickness, is there an outdoor sensor? What do you already have? Do you have a Pi, or something that can listen to BLE advertisements?
For temperature and humidity there are a lot of options. Personally would stay away from [DHT11]https://www.espruino.com/DHT11 and DHT22, those are inaccurate and annoying in my experience.
CO2 sensor question: Do you want to use it for indoor sensing to check CO2 created by humans, or do you have a greenhouse for example?
In the first case, you can use a chip like CCS811 that's relatively low power, and can indicate the presence of CO2 created by humans. This does not measure CO2, but uses some MEMS magic to "guess" CO2 levels. But fairly useful if the source is humans. And does have low-power mode & that is supported by the module.
If you have a greenhouse or anything else where the CO2 source is not humans, you would need a real CO2 sensor. I have an MHZ19, and did some initial testing based on this pull, and got it working with some datasheet reading and tweaking, but did not clean up my code.Distance and walls: If you have thin walls, simply using EspruinoHUB on for example a Raspberry to listen for BLE advertisements and sending measurements via BLE should work. BLE Espruinos go to sleep by default, so you should have a long battery life.
Wifi uses a lot more power, and takes time to connect, and in my experience it doesn't have much longer range thru walls than BLE. But if you have multiple access points that could cover your house.
If you must cover longer range, you would probably have to use an ISM radio. Or LoRa - probably it would be an overkill, but for example a cheap-ish TTGO Lora32 can act as a ready-to-use gateway with OpenMQTTGateway.
LoRa would have a massive range and work even if you have a massive greenhouse. Espruino lib for LoRa
Did some testing: MDBT42Q + RFM95W sending messages to TTGOLora32 "gateway", and that sends messages to my MQTT broker running on a Pi. And it does work. But don't have a full writeup... -
Did some hiking yesterday, and yes, the export did seem to stop ~halfway thru.
But: Run the export three times to KML and once to GPX, and the output stopped at four different times: roughly 2140-2150 records. It did not stop at the exact same time / record number.
And something was always wrong with the last record:
KML:
NaN,NaN,NaN
18.95,47.86064,NaN<< less significant digits in longitude, my position wasn't at "18.95"
NaN,47.86064,NaNLast GPX:
<trkpt lat="47" lon="NaN"> <ele>NaN</ele> <time>2020-03-29T09:46:34.000Z</time> </trkpt>But 2: copy-pasted the App Loader's console output from the browser, did some replace on the raw text, and looks like my whole trip is there, it was transfered by the Bangle, but the culprit is the parsing or export to GPX / KML.
5589 lines, 3 second interval -> some timestamps are missing, start and end timestamp and coordinates seem to be valid. -
@DerGuteWolf wasn't aware of that. That last link looks pretty useful.
Since Bangle uses a browser, it already knows the timezone offset: just type
new Date()in any browser console. It will have the tz offset of your computer. Change your system timezone to a different, andnew Date()changes to a different tz as well. So in 99.99% I think there would be no need for GPS position. Pre-select the timezone based on browser's tz, but allow the user to change it. Maybe?
But the code would have to figure out the DST change date. Haven't looked in detail, don't know if it's always unambiguous based on the browser's time zone.And to save flash, memory, and CPU cycles on the Bangle, I think actual calculation should be done in the browser, and only minimal data and logic should live on the Bangle.
-
Yepp, I increased the timezone by one (I'm at CET, that's +1 hour. Now it's set to +2 to show the current valid local time)
AFAIK GPS is UTC, so no DST change there.
DST is kind of crazy and weird, if you want to support all countries. So the best thing I think would be to expand the
Localeloader and load your selected country's next couple DST change dates. -
I'm not sure about disabling Bluetooth in Windows - won't that stop Web Bluetooth from working as well?
Sorry, disable and then re-enable it :)
-
Ok, that's good news. What windows version do you have? Altho, unless you completely disabled updates years ago, it should have working BLE support. Could you try unpairing and disabling Bluetooth on OS level?
Long shot, but do you have any program, that might interfere? Anything that might use Bluetooth, or even serial (might force itself on Bluetooth devices to look for characteristics it want to use)
Or as parasquid said, you can try a different OS.
Edit: Re: @Robin 's list: Tried a Feasycom dongle with external antenna (the one Gordon sells) on my work computer (desktop without built-in bluetooth, win10), and that worked just fine as well.
-
A single connection is expected: As soon as something connects to a BLE device, it stops advertising and maintains that single connection. At least in case of a Bangle.
I think if a tutorial / guide includes third party code/module/something, a version number would be really helpful. Most likely more informative than a simple last modified timestamp. (You mean last modified date on the docs site. For some reason Robin and / or MaBe seems to think about timestamp here?)
And a "support status" of the thing. Some JS modules state something like "Module xy is extremely beta.".
The docs site in my experience:
On the other hand: if there is no breaking change, stuff works just as it worked years ago, should someone just crawl the whole docs site, and bump last modified if it still works?
The link at the bottom of the page is useful: Last updated, and also list of commits, so you can the see changes as well.