OpenEPaperLink notes: Difference between revisions
mNo edit summary |
mNo edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{stub}} | |||
OpenEPaperLink is a project that uses various [[E-Paper]] devices -- primarily the little programmable labels that supermarkets use, | OpenEPaperLink is a project that uses various [[E-Paper]] devices -- primarily the little programmable labels (and larger ones that work the same) that supermarkets use, because they tend to be | ||
because they tend to | |||
* a display controller | * a display controller | ||
* a microcontroller | * a microcontroller (this project offers alternative software; the firmware on most takes is too proprietary to be useful) | ||
* some communication in them | * some communication in them | ||
:: The tags it focuses on are 802.15.4-based devices. | |||
<!-- | |||
:: there may be some additional features, like NFC | |||
:: and reacting to a RF jolt meaning "actually please wake up and update ''now'' rather than where you were planning" | |||
--> | |||
In a shop environment, there will be thousands, probably polling a central PC where thousands of labels in the store are kept track of, and with a protocol that authenticates (and maybe has some basic encryption?). | |||
(a | In this project, we poll a microcontroller (which probably handles a few dozen before everything because slow), no security, | ||
and we can afford to be makeshift and e.g. tell them apart by what's currently on there. | |||
- | Because such shop tags are battery-powered, and will use a moderate amount of energy to send and/or receive data, | ||
they check in as little as possible. | |||
They send in the most basic "do you have something new" and unless it gets a response within ''milliseconds'', | |||
it starts sleeping again. | |||
In the replacement firmware from this project, every 40 seconds is the ''fastest'' in normal use, apparently weak signals increase this to 10 minutes (because it would drain faster otherwise). | |||
===Tag AP=== | |||
This project's idea seems to be that, | |||
since every tag has a 802.15.4 radio, | |||
if you add an microcontroller to just one of these tags, you can take control of it, | |||
(custom firmware for both, ''and'' using the debug header on tags{{verify}}) | |||
you now have a tag that can act ''as'' that central checkin point for all nearby tags, | |||
saving a specialized RF device to make or buy. | |||
And since ESP32s have WiFi, you can now talk to that AP-Tag via WiFi, while ''it'' talks to the rest of the tags over 802.15.4. | |||
On the wifi side, it starts as an open WiFi AP network, and configured at 192.168.4.1, and you ''can'' use it that way (some icons won't display correctly but it's otherwise okay), | |||
: ...but it's intended to then configure it as a client onto your own WiFi and access it on there. | |||
Line 37: | Line 49: | ||
: e.g. https://github.com/jjwbruijn/OpenEPaperLink/wiki/Image-upload | : e.g. https://github.com/jjwbruijn/OpenEPaperLink/wiki/Image-upload | ||
Various people integrate with [[Home Assistant]] omstead (seems to use websockets over wifi(?)) | |||
Note that there is support to add ''more'' of these tag-APs to add coverage of more area -- they should automatically syncing the state of what to tell tags. | |||
The amount of tags a tag-AP (or set?) can handle is mostly limited by speed (possibly also RAM).{{verify}} | |||
It may be 30 on the low end but if you have more patience you can get more. | |||
but | |||
===Tags=== | |||
'''Firmware''' | |||
https://github.com/jjwbruijn/OpenEPaperLink/wiki/Firmware-Updates | |||
You can do OTA tag updates from the AP's filesystem. | |||
(how do you get them there?) | |||
===See also=== | |||
https://openepaperlink.de/ | https://openepaperlink.de/ | ||
https://github.com/jjwbruijn/OpenEPaperLink/wiki | https://github.com/jjwbruijn/OpenEPaperLink/wiki | ||
Latest revision as of 13:26, 30 April 2024
OpenEPaperLink is a project that uses various E-Paper devices -- primarily the little programmable labels (and larger ones that work the same) that supermarkets use, because they tend to be
- a display controller
- a microcontroller (this project offers alternative software; the firmware on most takes is too proprietary to be useful)
- some communication in them
- The tags it focuses on are 802.15.4-based devices.
In a shop environment, there will be thousands, probably polling a central PC where thousands of labels in the store are kept track of, and with a protocol that authenticates (and maybe has some basic encryption?).
In this project, we poll a microcontroller (which probably handles a few dozen before everything because slow), no security,
and we can afford to be makeshift and e.g. tell them apart by what's currently on there.
Because such shop tags are battery-powered, and will use a moderate amount of energy to send and/or receive data, they check in as little as possible.
They send in the most basic "do you have something new" and unless it gets a response within milliseconds, it starts sleeping again.
In the replacement firmware from this project, every 40 seconds is the fastest in normal use, apparently weak signals increase this to 10 minutes (because it would drain faster otherwise).
Tag AP
This project's idea seems to be that, since every tag has a 802.15.4 radio, if you add an microcontroller to just one of these tags, you can take control of it, (custom firmware for both, and using the debug header on tags(verify)) you now have a tag that can act as that central checkin point for all nearby tags, saving a specialized RF device to make or buy.
And since ESP32s have WiFi, you can now talk to that AP-Tag via WiFi, while it talks to the rest of the tags over 802.15.4.
On the wifi side, it starts as an open WiFi AP network, and configured at 192.168.4.1, and you can use it that way (some icons won't display correctly but it's otherwise okay),
- ...but it's intended to then configure it as a client onto your own WiFi and access it on there.
Regular API-like access can be made to this WiFi AP.
Various people integrate with Home Assistant omstead (seems to use websockets over wifi(?))
Note that there is support to add more of these tag-APs to add coverage of more area -- they should automatically syncing the state of what to tell tags.
The amount of tags a tag-AP (or set?) can handle is mostly limited by speed (possibly also RAM).(verify) It may be 30 on the low end but if you have more patience you can get more.
Tags
Firmware
https://github.com/jjwbruijn/OpenEPaperLink/wiki/Firmware-Updates
You can do OTA tag updates from the AP's filesystem. (how do you get them there?)