Hanhaa Symbisa IoT Dev Kit - Review

Table of contents

RoadTest: Hanhaa Symbisa IoT Dev Kit

Author: stevesmythe

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: I have used other IoT solutions such as the Onion Omega+, Raspberry Pi, ESP8266. These all require some programming and electronics knowledge.

What were the biggest problems encountered?: Inaccuracy of the humidity sensor.

Detailed Review:


About me

I am a self-employed IT Consultant based in London, UK. In my spare time I am a STEM Ambassador,an Assessor for the CREST Awards programme  and all-round electronics enthusiast. I have a BSc degree in Electronics and Physics from Edinburgh University.


What is the Hanhaa Symbisa IoT Dev Kit?

The Symbisa was originally a Kickstarter project. The Kickstarter project was cancelled when Hahaa obtained significant funding from a large electronics company. The result of this funding was Parcelive - a sophisticated parcel-tracking device that not only lets you know where your parcel is, but also whether it has been opened, dropped, turned upside down, is too hot, too humid etc.


The Symbisa appears to be a Parcelive repurposed as a consumer device (rather than a parcel service-provided device). The device can be purchased (in the UK at least) from the Hanhaa website for £90 plus VAT of £18. The Symbisa sends all the data via the GSM 2G network from its sensors to Hahaa’s Symbisa portal at intervals that the user can choose (1 minutes upwards). By logging onto their own account on the Symbisa portal, the user can see the data that has been received from the device. Since the Symbisa sends all its data every reporting interval, I am guessing that it is smart enough only to send new data that is not already on the portal.


The user buys ‘credits’ for their account and each time data is received by the portal, one ‘credit’ is used. You are provided with 100 credits when you obtain the device (Roadtesters received 500 credits). Further credits can also be purchased from the Hanhaa website for £9 for 1000 credits (plus VAT of £1.80).


The device has a 2.9” e-ink screen. From the portal, the user can send either a string or up to 25 characters to the device, and/or a bar code in Code39 format (up to 15 characters) to the screen. The data is transmitted and the screen updated the next time the Symbisa sends its data to the portal.


RoadTest objectives


My main objectives for this RoadTest were:

  • To explore various possible “use cases” to test the capabilities of the device (and associated software):
    1. To install the Symbisa inside a piano and remotely monitor its internal temperature and humidity to ensure that it is within the recommended parameters.
    2. To use the Symbisa to provide remote monitoring of a garden compost heap, to ensure that the composting process is progressing in an optimal manner.
    3. To use the Symbisa as a combined tracking and environmental monitoring device to monitor cycling or hiking conditions remotely.
  • To review the connectivity options.
  • To test the Symbisa web API with other connectivity solutions.





As can be seen from the above photos, the Kit consists of a nearly rectangular plastic case containing an L-shaped circuit board to which a LiPo battery pack and E-Ink screen are attached. The screen is an ED029TC1 reflective electrophoretic display module based on active matrix TFT substrate. It has 2.9” active area with 296×128 pixels. The L shape of the circuit board appears to be dictated by the antenna design – the long part of the “L” being the main antenna.


On the board you can see a 44 -pin STM32L443RCT low-power Arm Cortex 0+ 32-bit CPU with 256k of flash memory and a Quectel MC60CA Ultra-small LCC Quad-band GSM/GPRS/GNSS Module to provide 2G connectivity and GPS tracking.


Other notable features on the board are a micro-USB connector for charging the battery and configuring the device (and flashing new firmware), a push button and an empty SIM carrier.


The Symbisa uses an embedded SIM with mobile profiles loaded onto it. This enables Hanhaa to swap out mobile profiles over-the-air. The empty SIM carrier is presumably to allow for the possibility of using different SIMs in the future. The push button is used as an on-off button.


Getting started

Setting up an account

To use the Symbisa you first need to create an account on the Symbisa web site. Then you need to add the Symbisa device to your account by logging into the Symbisa portal and then clicking on the ‘Add Device’ button. Finally, you need to key in the serial number which can be found on the screen of the device and then part of the IMEI number which is provided on the back of the device.


Updating the device firmware

Before you can use the device, you need to update the device firmware (and charge the battery). To do this, you need to install some "updater" software from the Resources section of the portal website and download the latest firmware from the same page. You then load the firmware into the updater software, connect the USB cable and wait for it to update.


Initial problems

After I had first set up the device, I tried to view its data on the Hanhaa portal. Unfortunately, no data was being shown on the portal. Disappointing! I submitted a support request on the Hanhaa Support website. The problem was that the (v1.5) User Guide failed to mention that, after you have added the device details in the web portal, you have to reboot the device and then wait for around a minute. The User Guide didn't tell you how to do this either. Apparently, removing the battery does not reboot the device (I guess this is necessary to maintain data in the event that the battery is completely discharged). I fed this back to Hanhaa and the user guide was then updated to reflect this. Once I had followed these new instructions, the Symbisa started to send its data to the portal.


Use cases

1. Musical instrument monitoring

Pianos (and other musical instruments) should ideally be kept in conditions without large fluctuations in temperature or humidity. Pianos are largely made up of wood, felt, and metal.  Extreme levels of humidity, high or low, or a fluctuating humidity level, will have detrimental effects on all of these materials both in the short and long term. Ideal humidity levels are between 40% and 60%. Outside this range, the piano will require more frequent tuning and, in extreme or prolonged conditions, can develop cracked soundboards or rusty strings. There are many commercial humidity sensors available, with wifi or Bluetooth-connected apps, but I have not seen an IoT version. My first “use case” was to install the Symbisa inside my piano and monitor its internal temperature and humidity. I have fitted my piano with a humidity control system, so using the Symbisa should provide confirmation whether that is working as it should. I can envisage piano showrooms being interested in such a device as they could install it into their customer’s pianos and monitor them remotely. This type of application could be extended to other, vulnerable instruments such as violins and cellos. Here is the Symbisa strapped to the humidistat inside the piano. (The piano case is normally closed, of course).


I was slightly alarmed to see humidity levels of over 60% being reported. According to the manufacturers of the humidity control system, the humidity inside the case should be maintained between 40% and 50%. I therefore decided to check the measurements with a calibrated Honeywell HIH4000-001 humidity sensor attached to a Picaxe data logger.


The Honeywell HIH4000-001 humidity sensor produces an analogue output voltage that rises linearly with the relative humidity level (with an offset of 0.8v). Once calibrated, it provides very accurate readings. I ran the Symbisa and the Picaxe data logger side by side inside the piano’s case for several hours. Data appeared to show humidity around 46%, compared with Symbisa reading of over 60%. Temperature accuracy, as measured against a DS18B20 digital temperature sensor, seemed to be within specification. The Symbisa User Manual v1.6 claims that the humidity sensor has an accuracy of +/- 3.5% between 20% and 80% rH. Just to confirm the readings, I checked the both the Symbisa and the Picaxe data logger against a DHT22 humidity sensor connected to an Arduino microcontroller (admittedly not the most accurate sensor). This suggested that the Picaxe data logger’s readings were accurate and the Symbisa’s were not.


At this point, I decided to see if there had been a firmware update for the Symbisa since I first configured it. This turned out to be the case, so I updated the firmware from 1.0.0 to 1.1.10. As can be seen from the Excel data below (downloaded from the Symbisa portal), this immediately caused the humidity reading to drop from 64.5% to 58.4%. Surprisingly, it also caused the estimated battery % to fall from 73% to 57%. I conclude from this that Hanhaa were aware that the humidity (and battery) readings were inaccurate and had updated the firmware to compensate for this. However, the humidity readings were still too high and, worse still, continued to climb back almost to their previous levels. At this point, I decided to discontinue the exploration of this use case as the humidity data could not be relied upon. Possibly I have a faulty device (and I notice that another Roadtester experienced spurious readings from their device).




Assuming that the humidity readings can be made more reliable, this “use case” appears to be a promising one. Piano dealers could lend their customers a Symbisa device and remotely monitor not just the humidity inside the customer’s house, but also inside the piano itself. This would provide the customer with the information they need to decide whether to invest in a humidity control system. Once fitted, it would give reassurance that all was well and that their piano is being maintained within safe environmental conditions.


2. Composting

I have a compost heap in my garden. To make good compost, the process needs the right balance of “green” and “brown” vegetable matter and the right amount of moisture. After identifying a suitable protective container, I wanted to see whether the Symbisa would provide useful feedback on the composting process (and how deep in the compost it could go before its signal was lost). If successful, this “use case” could lead to more efficient composting, which is of increasing importance for protecting the environment. Even if the compost experiment was unsuccessful, I can see other applications for horticulture, such as greenhouse temperature and humidity control.


I had been neglecting my compost heap recently and the composting rate had slowed right down. However, I needed to prune my Eucalyptus tree and this provided a good opportunity to monitor the composting process with the Symbisa. I have found, from previous experience, that putting the Eucalyptus cuttings through the garden shredder results in a great mix of “green” and “brown” matter – just right for triggering the composting process. Some people say that Eucalyptus shouldn’t be used in compost because the antibacterial, antifungal and allelopathic properties of eucalyptus terpenes and phenols are detrimental to compost production. In my experience, as long as you have a big pile that gets hot enough, it is absolutely fine. The operating parameters for the Symbisa (as per the User Guide) are temperatures from -15 deg C to +50 deg C (limited by the operating temperature range of the lithium polymer battery) and humidity from 5% to 90% non-condensing. Hot composting can sometimes exceed the upper end of that temperature range, so I kept a keen eye on the temperature.


Before putting my Symbisa into my compost heap, I had a think about how to protect it from water, organisms and micro-organisms and also from my spade, when I was turning the heap. As I wasn’t interested in the humidity levels of the compost heap (especially given the unreliability of measurements I had experienced), I put the Symbisa inside an airtight plastic box.


I initially carried out some testing to see how deep I could bury the Symbisa and still receive a good GSM signal from it. Surprisingly, the device communicated well at a depth of over 30cm (12 inches). I was able to monitor the GSM signal quality as the Symbisa reports this via the CSQ parameter (measured according to the Quectel scale). I found that a CSQ value of 15 or over was pretty reliable. In contrast, the GPS signal was lost very quickly even at shallow depths of 5cm or more.


Because my compost heap had been somewhat dormant for a while, the temperature recorded when I first buried the Symbisa was only 18.2 degrees Celsius. The relative humidity was 60%. After rising steadily at a rate of 0.1C per hour for almost two days, reaching a high of 26.1 degrees, the composting process appeared to stall and the temperature fell slowly to 25.5 over the next few hours. I decided that some intervention was needed, so I gave the compost a mix. This resulted in some of the already composted material at the bottom of the heap being mixed with the newly-introduced Eucalyptus shreddings, as well as introducing more air into the heap (hot composting is an aerobic process). After a couple of hours, the temperature started to rise again, but much faster (initially 0.6 degrees per hour, then slowing to 0.3 deg per hour). After three more days I retrieved the Symbisa, removed it from its box to check that it hadn't been invaded by worms (it was fine) and put it back! Releasing it from its box into fresh air caused the humidity to drop sharply, but it soon increased again.




Six days after the Symbisa was first buried, the temperature had risen to 46 deg and the humidity to 93.7 (which is outside the Symbisa’s operating parameters but probably spurious). I decided to stop the experiment at this point as it was clear that, after the initial slow start, the composting process was proceeding nicely. The Symbisa had helped identify that the composting process had not been working optimally, and allowed me to correct the mixture. It is possible to get temperature probes that do the same thing, but these do not generally have the option of remote monitoring.


3. Activity tracking and environmental monitoring

The idea behind this potential “use case” was that the Symbisa would be used to track and monitor remotely the location and environmental conditions of groups of hikers, such as school adventure trips or challenges.


In the past, young people on such expeditions have lost their way and/or succumbed to bad weather conditions. Conditions such as hypothermia affect cognitive ability and it is not always the case that someone in trouble will actively seek help. The use of a Symbisa as an additional safety device could enable event organisers to monitor conditions on the ground, track progress and potentially send messages to the hikers. This use case does depend on there being a useable 2G signal, so you would need to ensure that there was 2G coverage in the locations where the trip was taking place. One of the things I like about the Symbisa is that location tracking will revert to cell ID and GSM latitude and longitude of the 2G signal if the GPS signal is insufficient. This, of course, does result in lower precision location information, but it is clear from the portal whether you are looking at GPS or GSM location information. To demonstrate this, the screenshot below is tracking information from a boat trip I made down the middle of the River Orwell in the UK. The Symbisa was actually in my rucksack below deck, and it was a cloudy, rainy day, so the GPS signal quality was poor. In places, my position is shown as being in the middle of the river and a couple of times my boat appears to be on dry land!




**** This section was updated on 02 November 2018 after taking the Symbisa on a couple of hikes ****


Dartmoor in England is a large wilderness area in the South-west of England. Due to its size and remoteness, it is often used by the army for training exercises, and it is also often used for challenge events, to test young people's map-reading and survival skills. I took the Symbisa out into the middle of the moor in October 2018 to try and find a geocache whose location I only knew with low precision. The maps below show my movements over a period of a couple of hours.



The map above shows two spurious outliers, which were caused by the Symbisa losing its GPS fix and falling back to the GSM cellular location. The map below shows a more detailed view of my actual location (ignoring the lines to/from the outliers). In practice, provided the readings are taken close together (these were every 15 minutes) and the Symbisa can "see" the sky, location tracking works well. However, near-realtime tracking does depend on having a GSM signal. As a previous RoadTester noted, the readings are not cached; if there is no GSM signal at the prescribed notification time, sensor data is simply lost forever. For this particular use-case, it would be better if cached data could be sent the next time the Symbisa has a GSM signal, rather than waiting for the next notification period.


Finally, here is another example of a hike in the Kent countryside. The same issue was encountered (GSM outliers providing misleading location information).




Connectivity Options


The original Symbisa Kickstarter project alluded to the possibility that some GPIO pins would be exposed to enable the direct connection of other devices to the Symbisa. Having taken the Symbisa out of its case, it is clear that this is not so with the version we RoadTested. I think this is a pity, as it would have opened up the device to more applications and the ability to add more sensors.


Similarly, the original Kickstarter suggested that it would be possible to connect with the Symbisa using the popular block-based educational software Scratch. This would have enabled students to develop simple programs to gain access to the sensor data and to write messages to the screen. Alas, this feature did not make it to the finished device either.


Using the web API


Because it is not possible to connect directly to the Symbisa, this rules out the addition of other components. I thought it might be useful to have an “alert system” to emit an audible warning, or flash an LED if sensor data falls outside of specified parameters. For example, an alert could be triggered if the piano’s humidity control system had failed, or if a group of hikers was experiencing extreme temperatures.


I decided to use a Raspberry Pi Zero fitted with a “traffic lights LED” as a supplementary “alert system”. This involved writing a Python script to download the data (within a specified time period) from the Symbisa portal and displaying the data of interest (in my case, temperature and humidity) on an eight-digit seven-segment display. (I happened to have one of these spare). The script compares the data to see if the temperature is within specified limits and, if not, turns on an amber or red LED. Otherwise a green LED is turned on. For the purposes of this test, I set some arbitrary humidity limits (green=62%RH or less, amber=62% to 64%RH, red=higher than 64%). You can see that the dates/times in the video below correspond with the screenshot of data from the Symbisa portal underneath.




The Python code is below.


# /etc/init.d/SYMBISA-7_SEG.py


# Provides:          SYMBISA-7_seg.py

# Required-Start:    $remote_fs $syslog

# Required-Stop:    $remote_fs $syslog

# Default-Start:    2 3 4 5

# Default-Stop:      0 1 6

# Short-Description: Start daemon at boot time

# Description:      Enable service provided by daemon.



import time

import datetime as dt # module used for manipulating dates

import RPi.GPIO as GPIO

from luma.led_matrix.device import max7219

from luma.core.interface.serial import spi, noop

from luma.core.virtual import viewport, sevensegment


import requests

import json


# setup GPIO pins for traffic light


RED, YELLOW, GREEN = 0, 1, 2


for led in (RED, YELLOW, GREEN):

        GPIO.setup(LED[led], GPIO.OUT, initial=0)


# the ?start parameter below is Unix epoch time in milliseconds (see https://www.epochconverter.com/)

response = requests.get('https://symbisa.hanhaa.net/portal/api/data/interval?start=1539550800000', headers={"Authorization": "bearer " + 'xxxxxxxxxxxxxxx'})




# create seven segment device

serial = spi(port=0, device=0, gpio=noop())

device = max7219(serial, cascaded=1)

seg = sevensegment(device)


# Loop printing measurements every second.

#print('Press Ctrl-C to quit.')

while True:



        for item in data:




                inDate =item['trackingDate']

                d = dt.datetime.strptime(inDate, "%Y-%m-%d %H:%M:%S")

                tracktime = d + dt.timedelta(hours=1) # daylight saving adjustment


                if hum_float>68:

                        GPIO.output(40,1) #red



                elif hum_float>64:


                        GPIO.output(38,1) #amber





                        GPIO.output(36,1) #green





                tempdisp=('%.1f' % temp)

                seg.text = "t - " + str(tempdisp) + "c"



                humdisp=('%.1f' % hum)

                seg.text = "RH - " + str(humdisp)




For security, I have replaced my credentials in the code with “xxxxxxxxxxxxxxx”.


The Python code uses the “requests” module to make the HTTP request. This returns the Symbisa data in JSON format. The “json” module is then called to extract the data from that. The key parts of the code that get the data from the portal are:

import requests
import json
1539550800000', headers={"Authorization": "bearer " + 'your API key'})


[You need to substitute a valid API key where it says ‘your API key’. You can generate a valid API key from the API Keys submenu on the Symbisa portal. This will be a very long string of characters]


The ‘interval?start=’ parameter is the Unix timestamp representing the date and time from which you want to download the data. This is the number of milliseconds since the Unix Epoch started on 1 January 1970.


I can imagine a headteacher having one of these Raspberry Pi monitoring devices on his/her desk during a school adventure hike, to give reassurance that the students were not experiencing extreme weather conditions!


Using the Excel add-in


**** This section was updated on 23 October 2018 after testing the Hanhaa Excel template with the add-in ****

Apart from viewing data on the Hanhaa web portal or on another device via the API, it is possible to view the portal data (retrospectively) via an Excel add-in. This appeared to work well, although it was a bit of a fiddle to get it installed in the first place because the add-in had not yet been added to the Windows Store and had to be "side-loaded". The add-in has now (October 2018) been added to the Windows Store but it is not currently visible (apparently it will be visible/searchable from February 2019). To get the add-in, open Microsoft Excel, and in a workbook navigate to Insert>Get Add-ins. Then search for: WA104381795 (Case sensitive). This will bring up the Symbisa Add-in for you to install.


Unfortunately for us "early adopters", it wasn't that simple as there is no easy way to uninstall the "side-loaded" add-in. However, after a few emails exchanged via Hanhaa Support, I got it working. Hanhaa have provided a template that demonstrates how you can see the live portal data in an Excel sheet, and it also allows you to send a message and/or bar code to the device. The screenshot below shows how it looks. Alternatively, it is pretty easy to use the add-in to get Symbisa data into your own spreadsheet.





Returning to my main objectives for the RoadTest:

  • To explore various possible “use cases” to test the capabilities of the device (and associated software).
  • To review the connectivity options.
  • To test the Symbisa web API with other connectivity solutions.


My evaluation is that:

  • I think that all three use cases that I tested showed that the Symbisa and associated website/software have potential applications outside the parcel-tracking business, although the reliability of some of the sensors' readings needs to be improved.
  • The connectivity options are, in my opinion, disappointing. Apart from providing remote access to "after the event" data, it is not possible to connect other devices to the Symbisa and even the excellent built-in screen cannot be used to view sensor data.
  • I found the web API relatively straightforward to use. Apart from the fact that you can only see "after the event" data, using an Internet-connected microcontroller such as a Raspberry Pi does allow you to build-in further automation and decision-making based on the Symbisa's sensor data.


I found some "bugs" with the portal.


  • On the portal dashboard, the “Light/Opened” box is always green, even with a light level of 0.0 Lux
  • On the portal dashboard (“Track detail”), it is not clear whether the column headed “Light” - is “Average light value within the reporting interval” as per the manual or "instantaneous light value when reported".
  • I saw a humidity reading of 100% when I breathed on the sensor a couple of times. This reading displayed differently, depending on where you looked (see screenshots). On the "Track detail" screen, it showed as 100% (as per the screenshot below).


On the "Data sheet" section of the main portal page it showed as "-" and on the map section of the same page, it showed as blank. (See the next screenshot). Readings of 100% also crashed my Raspberry Pi Python "remote API" program, as my program expected a floating point number but received a null.




The Symbisa is a really cool device and makes the “Internet of Things” something that anybody can use, without knowing anything about coding or electronics. Unlike most IoT devices, it does not rely on a wireless Internet connection or Bluetooth to provide remote access. It can therefore be used in many more locations and “use cases”. However, with its current firmware, it falls well short of meeting its potential. The screen is a good example. This is a high-quality 2.7” e-ink display, capable of displaying text and bit-mapped graphics and yet the user is limited to sending a single line of 25 characters and/or a bar code to it.


It is early days yet, but it seems that the business model that Hanhaa has adopted for the Symbisa is to limit direct access to the device so that users need to buy credits for Hanhaa’s own 2G network to access the data. The only access to the device’s data is via the Symbisa web portal, and then only after the device has sent its data on a periodic basis to the portal. In other words, not only is there no real-time physical access to the device itself, there is no real-time remote access either. This rules out any applications involving real-time monitoring of data. The nearest you can get to real-time is by reducing the reporting time to the minimum (1 minute), which means that more credits will be used.


Considering that the Symbisa has a high-quality built-in e-paper display, this is crazy from the consumer’s point of view. People who have paid £108 for an IoT sensor device with an e-ink display will be surprised and disappointed to find that they can’t see the sensor data on the device’s own screen! I’m sure that it would be a trivial matter for Hanhaa to program the device to display sensor data directly onto the screen and/or send the data to the portal, depending on what the user needs. There are also no guarantees that Hanhaa will not cease trading, or turn off the web portal, or increase the cost of credits. The consumer would then be left with a completely useless device.


Hanhaa already have the Parcelive device – which appears to have a lot of commercial potential in the logistics industry. I had thought that the idea of the Symbisa (which has identical hardware) was to open up new business opportunities by providing a different feature set and business model. By keeping it as a closed, proprietary system, I can’t see this happening.


The use of the Quectel MC60CA Ultra-small LCC Quad-band GSM/GPRS/GNSS suggests that using the current iteration of the device over 3G or 4G will not be possible. This will limit the rollout of the device to countries that have already phased out 2G mobile signal, or are planning to do so.


Hanhaa provide a Support portal where you can raise tickets and ask questions. Although response was initially slow, this did improve during the Roadtest. However, Hanhaa seem quite cagey about providing information about the device. For example, there is no way of knowing what is the latest firmware update or what is contained in it. When I asked for a list of what was in firmware 1.1.10, compared with 1.0.0 I was just told that it had been updated to improve the accuracy of temperature and humidity reporting although it was obvious from the device data that the reporting of battery level had also been changed. It is also really hard to find the latest User Manual. You would think that it would be easy to download from the portal, under the Resources section or maybe in the Support portal under Knowledge Base, but it is not there. Similarly, according to the User Manual there is supposed to be an Excel template for viewing sensor data which would save you having to set up an Excel sheet from scratch, but that was not there either when I looked. After contacting Hanhaa Support, I was sent the template and this report was updated (see above).


It is early days yet and I hope that Hanhaa do end up providing more flexible and configurable firmware for the Symbisa to make it a more useful device for a range of use-cases.


Thanks to element14, Hanhaa and for giving me the opportunity to carry out this RoadTest


Postscript - July 2021

Fellow RoadTesters vlasov01, gam3t3ch, jpnbino and marcosfg (as well as anybody who bought a Symbisa) will be dismayed to learn that Hanhaa have deprecated this product.


I discovered recently that the Symbisa web portal didn't seem to be working and contacted Hanhaa. In response, one of their people called me up to find out what the issue was. Having joined the company recently, it turned out that he had no idea what a Symbisa was! Long story short, they have turned off the web portal for Symbisa. They told me that they had tried to contact all their Symbisa customers and warn them but I guess that didn't include us RoadTesters.


They continue to support the Parcelive web portal and they sent me a Parcelive device as a "replacement" on a trial basis. As you can see from the photo, it is indeed an identical device - only the firmware is different.


Unlike the Symbisa, you can't configure the device yourself, so they ask you in advance how often you want the device to send its data to the portal over 2G and what sensors you want to report from. With the Symbisa, you could choose the reporting period and sensor reporting yourself.


Parcelive portal screenshot below:



Once the trial is finished (when the data runs out), I think the expectation is that I send the device back using the packaging provided. Then I guess they will want to sell me a subscription. Instead, I think I will just salvage the e-ink display and LiPo battery and put the rest in the bin.


As I said in my review "There are also no guarantees that Hanhaa will not cease trading, or turn off the web portal, or increase the cost of credits. The consumer would then be left with a completely useless device."

Parents Comment Children
No Data