iBeacon?

[btsimonh]

Hi victor,

strikes me that this hardware is so cheap in comparison to any form of 'iBeacon' that an iBeacon mode may be a useful addition. I'm not sure what make something an 'iBeacon', but I'm guessing that the main features would be a known (and stable) tx power (and possibly adjustable?) included with the data. And for 'true' iBeacon functionality, an (additional?) advert in iBeacon format?

Possible applications: Carry it with you for person location within the house. Using a number of fixed location units for internal robot positioning (e.g. now the ESP32 seems more stable for BLE). (indeed, use outside in even a large garden for external robot location).

questions that may need to answered: How stable is the tx power with waking from sleep, etc. and battery condition? How often does a 'normal' iBeacon advertise & affect on battery life?

For the adventurous, people could even upgrade to 3.3v power - I read somewhere that with 3.3v, the txpower can be higher....

thoughts?

s

p.s. another 'stupid' idea - I'm on the verge of completing the new BLE drivers for Tasmota. One of the features that I put in is to use the MAC from the advert data rather than the advert source for sensor identification. The effect being that theoretically adverts could be heard by one unit, and forwarded on to be heard by a more remote Tasmota - a bit like a sensor mesh. I'm assuming that this hardware would be capable of hearing advertisements, but that battery drain would be significant with radio reception being on all the time. The only advantage of having an 03mmc do the forwarding is that it is nicely packaged and batter powered, so it MAY be advantageous even if the battery only lasted 3 months. If the battery only lasted 2 weeks, another matter (unless 2 x AA are used instead...). Sorry to put two things in one issue!

[pvvx]

Samsung Galaxy SmartTag. Tag/iBeacon/Eddystone requires different firmware optimized for these features.

[pvvx]

p.s. another 'stupid' idea - I'm on the verge of completing the new BLE drivers for Tasmota.

Inventing ZigBee? TLSR825x works in ZigBee. I have been doing a ZigBee test firmware for LYWSD03MMC (tl_zigbee_sdk). The consumption is slightly higher... In tl_zigbee_ble_concurrent_sdk, consumption is much higher and CR2032 is not suitable. In 'Telink BLE Homekit SDK' (Apple) - consumption is much higher and CR2032 is not suitable (>30 uA).

[btsimonh]

"Samsung Galaxy SmartTag" - 10 x the price :(. So, from what you have said, measuring the rssi from the MI units would give very poor distance resolution - room presence may be ok, but positioning within the room decidedly dodgy ...

Interesting that the same hardware supports zigbee.... I had the impression that zigbee was a tightly protected technology :).

thanks for your quick answers.

One final question, and an observation..

Q: I have another MI sensor where the BLE name is writable. I've not pulled the battery to see if it's persistent. Being able to set a persistent BLE name on the pvvx firmware may be a nice addition.

Observation based on implementing a receiver: The 'all' mode is difficult to interpret because: 1/ there can be more than one service data per advert - this is the only 'mi style' sensor which does this? (e.g. the Tasmota code always only looked at the first service data). 2/ the type of service data sent changes (obviously, because it's sending 'all'!). The current Tasmota driver detects the sensor type from the (first in packet) servicedata, and so flips between sensor types. You may find that other receivers behave in similar ways. For the moment, I just log an error when this happens. Maybe it should always send one type as the first servicedata in every packet (e.g. MI style for highest compatibility?), and append one of the two custom types for those receivers who understand it and prefer it?

Having said that, I have implemented your new custom packet, and it's working well. Both me and another guy had some troubles with configuration, but once we got it sending a single type, it was ok.

p.s. I've also created a 'TelelinkFlasher' page, mainly for ease of obtaining the keys for real MI sensors - it takes a query string containing MAC and a callback link. The page helps the user get the key, and then calls back into Tasmota to directly set the key in Tas. I assume your telelink flasher page is different to ATC's in terms of configuration, so I have linked both at the top of the page if that's ok? In the longer term, it may be nice to be able to identify the firmware present in a sensor, and link to a specific config page for that firmware, but it's a job for another day. You can see the page here: https://btsimonh.github.io/atc1441.github.io/TelinkFlasherTasmota.html?mac=A4C1387FC1E1&cb=http%3A%2F%2F192.168.1.212%2Fmikey

[pvvx]

1/ there can be more than one service data per advert - this is the only 'mi style' sensor which does this? (e.g. the Tasmota code always only looked at the first service data). 2/ the type of service data sent changes (obviously, because it's sending 'all'!). The current Tasmota driver detects the sensor type from the (first in packet) servicedata, and so flips between sensor types. You may find that other receivers behave in similar ways. For the moment, I just log an error when this happens.

This is wrong. There is a data block size.

[pvvx]

It is necessary to come up with such a format so that the "memory protection" error appears in the Tasmota software due to viewing data without taking into account the size. Otherwise they won't fix it.

[btsimonh]

agreed, but 'existing' implementations don't necessarily use this to distinguish between, for example, pvvx custom and atc custom. seems there will be at least 5 existing implementations receiving atc (i've seen a few in searches). Tasmota does now distinguish based on block size, and also checks the mac reversal.... but it still can't know what sensor it is from the first 'all' packet. "Otherwise they won't fix it." - haha - been working on Tas BLE for the last 6 weeks! (I have NOT changed the implementation based on external BLE interfaces .... only the ESP32 internal, and only if using my new driver).

[pvvx]

So, from what you have said, measuring the rssi from the MI units would give very poor distance resolution - room presence may be ok, but positioning within the room decidedly dodgy ...

Telink_AOA_AOD: https://yadi.sk/d/cOBQgTTn7-oPew https://item.taobao.com/item.htm?spm=a1z10.1-c.w137644-22775676694.40.27fc36c7fZFdT6&id=619947022066

[pvvx]

In the longer term, it may be nice to be able to identify the firmware present in a sensor, and link to a specific config page for that firmware, but it's a job for another day.

Fit custom MAC and device name setting?

[btsimonh]

positioning - I want one - if I had time for another project! "Fit custom MAC and device name setting?" - no, I mean just in Tasmota to present a link to a config page which is correct for a specific firmware version. e.g. if we could read the version via some characteristic, then maybe we go to a generic page, do the connect, and then redirect to the appropriate page (or have one page which addresses all firmwares - but that seems harder to maintain when firmwares change.... But it's not a problem, just a thought. - when making my page, then finding your firmware, I realised that my page was out of date before it even became live (based on ATC page)!

[pvvx]

if we could read the version via some characteristic,

SERVICE_UUID_DEVICE_INFORMATION 0x180A

SYSTEM_ID_UUID 0x2A23 // System ID MODEL_NUMBER_UUID 0x2A24 // Model Number String SERIAL_NUMBER_UUID 0x2A25 // Serial Number String FIRMWARE_REV_UUID 0x2A26 // Firmware Revision String HARDWARE_REV_UUID 0x2A27 // Hardware Revision String SOFTWARE_REV_UUID 0x2A28 // Software Revision String MANUFACTURER_NAME_UUID 0x2A29 // Manufacturer Name String IEEE_11073_CERT_DATA_UUID 0x2A2A // IEEE 11073-20601 Regulatory Certification Data List ?

[btsimonh]

I have another 10 devices on order... so I'm sure I will be here bothering you for a while - but maybe in a couple of months (delivery time). For me, the first interesting thing would be to be able to write the device name, and store in flash (i.e. i'd like to name all my devices....). The second thing would be the configuration webpage - but this would benefit others rather than us - and this is something that I could do alone with some advice.

If you use ESP32 & tasmota, give the new BLE a go. PR just merged - supports the custom format.

[rjblake]

@btsimonh - I'm waiting on some ESP32s and looking to use Tasmota or other to get the data and provide to Domoticz. Prefer to go this route vs. polling the devices (have 8 already) to get readings. Does the new PR work with the firmware from Victor or that from Aaron? I have a Python programming that listens for broadcasts, but have yet to modify for Victor's format, so have to discard the readings that are obviously not formatted correctly. Curious how you differentiate between the two.

[pvvx]

For me, the first interesting thing would be to be able to write the device name, and store in flash (i.e. i'd like to name all my devices....).

Version 1.4 : added Get/Set device name, Get/Set MAC

[btsimonh]

:) will test later.

[btsimonh]

hmm.... 09:06:49.919 MQT: tele/tasmota_esp32/BLE = {"BLEOperation":{"opid":"6","stat":"-4","state":"FAILCANTWRITE","MAC":"A4C1386A1E24","svc":"0x1800","char":"0x2a00","write":"68656C6C6F"}}

expected in on 1800/2a00 - but read of this gives 'ATC', and write is unwritable.

Name from advert gives the name I set in your config page.

[btsimonh]

looks like this line reads the name.... {0,ATT_PERMISSIONS_READ,2,sizeof(my_devName), (u8)(&my_devNameUUID), (u8)(my_devName), 0}, -> ATC.

googled example of RDWR with callback: (may be of help?) {0,ATT_PERMISSIONS_RDWR,16,sizeof(SppData_1),(u8)(&TelinkSppDataServer2ClientUUID), (u8)(SppData_1), (att_readwrite_callback_t)&module_onReceiveData}, //value

(https://github.com/Qiu-zhangbao/TLSR8258_BLE/blob/6f7f4d18a0db9e36affdb5ee3d5df78637628487/example/at/app_att.c)

[pvvx]

v1.5: Add Standard Device Information Characteristics

[btsimonh]

:) - heading in a direction towards a writable name ....

[pvvx]

The RDWR attribute is too heavy code and not necessary for everyone. Causes security troubles if no PIN is not applicable. And many problems with the pin-code in Windows 10...

[btsimonh]

:( just a nice to have. Would rather without pin code.... my older MI sensors support setting the name - i was surprised :)

[pvvx]

Any passerby change the device name?

[btsimonh]

so, the TAS firmware does not do any auth on connect.... so yes, I guess. :). For me, I don't care - but my neighbours are far..... but then again, they can see the name, I guess you can't trigger pairing (no button?) - so it's not that protected? If they know it's a pvvx sensor, then they are in?

[btsimonh]

I hate all the security implications. The robber walks past your house and finds the rooms are at 15C (from adverts) - so they know you are on holiday? But then I like easy access to everything....

[pvvx]

The device name changes in the menu when connected by a special command. PIN is an option for security. Children love to play. The sources are published - change it as you like. :)

[pvvx]

I guess you can't trigger pairing (no button?) - so it's not that protected?

Binding / pairing and pin code is entered without a button on the device. Pin-code is requested by the application on the first connection.

[pvvx]

Android stores pin codes from multiple devices. Windows 10 remembers only 1 pin code and for many devices it must be deleted in the BT menu - there are dependencies on the BT adapter drivers.

[btsimonh]

bt is a right pain.....

[pvvx]

If you do not know the PIN-code, then by default the system will send the code "000000" and / or "123456". Don't use the code "123456" :)

[btsimonh]

hi pvvx, i see you are progressing fast :) - and attracting lots of attention. I just flashed 1.7 .....

From my brief read of commits, it seems that you intend that the pin is optional. I set the name using the command in the flasher html (a few issues with it disconnecting?), and the name comes in as I expect. Also, reading the name through a BLE connect/read is ok. - so pin auth not required to connect? But writing the name give 'not writable':

19:25:52.605 CMD: blename fred
19:25:52.610 RSL: stat/tasmota_E89E98/RESULT = {"BLEName":"Done"}
19:25:55.954 RSL: tele/tasmota_E89E98/BLE = {"BLEOperation":{"opid":"25","stat":"3","state":"DONEREAD","MAC":"A4C1386A1E24","svc":"0x1800","char":"0x2a00","read":"4D7954657374"}}
19:26:22.957 CMD: blename fred james
19:26:22.962 RSL: stat/tasmota_E89E98/RESULT = {"BLEName":"Done"}
19:26:25.956 RSL: tele/tasmota_E89E98/BLE = {"BLEOperation":{"opid":"26","stat":"-4","state":"FAILCANTWRITE","MAC":"A4C1386A1E24","svc":"0x1800","char":"0x2a00","write":"6A616D6573"}}

Did I read the commits wrong, or is this as intended?

hmmm.. seems the characteristic is still readonly? {0,ATT_PERMISSIONS_READ,2,3, (u8*)(&my_devNameUUID), (u8*)&ble_name[2], 0},

[btsimonh]

very small issue with webpage - you can hit start flash twice quickly. was scared when i did this, but flash completed ok, with a small error. - but could be locked out. About to flash 8, so will let you know if any issues :)