OpenEPaperLink notes: Difference between revisions

Latest revision as of 13:26, 30 April 2024

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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.

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.

@@ 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 microcontroller
+* 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.
+<!--
+:: 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?).
+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.
-The tags it focuses on are 802.15.4-based devices.
+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).
-Regardless of how they worked originally, these will poll a shop AP, which sends them new information when they should.
-(a shop will also spend a lot of time trying to keep track of the thousands of labels they have around. We can afford to be a bit messier.)
--->
+===Tag AP===
-<!--
 This project's idea seems to be that,
-since every tag has a 802.15.4 radio (its own protocol?),
+since every tag has a 802.15.4 radio,
-if you add an ESP32 (with specific firmware) to just one of these tags (with a specific connection - the tags have a debug header),
+if you add an microcontroller to just one of these tags, you can take control of it,
-you now have a tag that can ''be'' that central checkin point of the tags, saving one more device to buy.
+(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.
+: e.g. https://github.com/jjwbruijn/OpenEPaperLink/wiki/Image-upload
-There is a "just add APs and it will sync everything automatically and give better coverage" thing
+Various people integrate with [[Home Assistant]] omstead (seems to use websockets over wifi(?))
-The amount of tags an AP (or set?) can handle (remember images for) is around 30 for a xx MB PSRAM ESP32.
+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.
-Regular API-like access can be made to this WiFi AP.
-: e.g. https://github.com/jjwbruijn/OpenEPaperLink/wiki/Image-upload
+===Tags===
-You can also integrate with home assistant - this uses websockets over wifi(?)
+'''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?)
-Tags use a moderate amount of energy to send and/or receive data, so to last a long time they check in as little as possible.
-Every 40 seconds is the ''fastest'' in normal use, apparently weak signals increase this to 10 minutes (because it would drain faster otherwise).
-Also, they send in the most basic "do you have something new" and unless it gets a response within ''milliseconds'', it sleeps again.
+===See also===
 https://openepaperlink.de/
 https://github.com/jjwbruijn/OpenEPaperLink/wiki
--->

OpenEPaperLink notes: Difference between revisions

Latest revision as of 13:26, 30 April 2024

Tag AP

Tags

See also

Navigation menu