Hello
I have NodOn NIU buttons (Bluetooth Low Energy BLE) but I can’t find them on the list of compatible hardware Theengs gateway (link)
Has anyone managed to integrate these buttons?
Welcome @Domsrx06
Nobody has asked for an integration of the NodOn NIU buttons so far, but you can do the following so we can see if it might be possible to create a decoder for them.
Set Advertisement and Advanced Data to true and then monitor the button’s raw undecoded advertising broadcasts with MQTT Explorer, also with the various different button presses.
If the advertisement data changes with the button presses it will be possible to create a decoder for them, but I somehow assume it might be similar to other BLE trackers with buttons, that you have to connect and register for notifications for the button presses, which is not in the scope of Theengs Decoder, the BLE library OpenMQTTGateway and Theengs gateway use.
Let us know what raw data you get with the above.
P. S.: I also just saw your posting on the Jeedom forum and that you previously had the buttons recognised with the BLEA plug-in. So with some samples from you as described above and looking at the BLEA source it should likely be possible to create a decoder for them for OpenMQTTGateway and Theengs Gateway as well 
Also as you seem to be using Theengs Gateway, the setting equivalent to the OpenMQTTGateway setting I liked to above is
-padv PUBLISH_ADVDATA, --publish_advdata PUBLISH_ADVDATA
Publish advertising and advanced data (1) or not (0)
(default: 0)
The option for showing advanced and advertising data has now also been added in the new beta of the Jeedom Theengs Gateway Plug-in
Hello @DigiH
I have installed the Theengs Gateway on my Jeedom Atlas
Then using MQTT Explorer, this is what is received while pushing NodOn NIU button
Can we integrate NodOn NIU button with those information ?
{
"name": "NIU",
"id": "ED:DE:05:8B:AE:2A",
"rssi": -59,
"servicedatauuid": "0000",
"servicedata": "02599c37d90287a5215200065f000004"
}
“servicedata”: “02599c37d90287a521520006635ab801” 1 short click
“servicedata”: “02599c37d90287a52152000663ee4b02” 1 double click
“servicedata”: “02599c37d90287a52152000660259003” 1 long press
then
“servicedata”: “02599c37d90287a521520006622b8104” button release
i also receive this which i am not able to associate to an action
“servicedata”: “02599c37d90287a5215200065f000004”
“servicedata”: “02599c37d90287a5215200065f95da03”
“servicedata”: “02599c37d90287a5215200065f4f2402”
“servicedata”: “02599c37d90287a521520006604e1201”
“servicedata”: “02599c37d90287a521520006625eb901”
In Jeedom Bluetooth Advertisement (blea) plugin i was using 4 status :
“simple appui” short click
“double appui” double click
“appui long” long press
“relachement” release
For your information Jeedom (blea) Python code
html/plugins/blea/resources/blead/devices/niu.py
from bluepy.btle import Scanner, DefaultDelegate
import time
import logging
import globals
class Niu():
def __init__(self):
self.name = 'niu'
self.ignoreRepeat = False
def isvalid(self,name,manuf='',data='',mac=''):
if name.lower() == self.name:
return True
def parse(self,data,mac,name,manuf):
action={}
logging.debug('Parsing data ' + data)
buttontrame = data[34:36]
batterytrame = data[28:30]
colortrame = data[24:28]
battery = str(int(batterytrame,16))
if colortrame == '0001':
color = 'No color'
elif colortrame == '0002':
color = 'White'
elif colortrame == '0003':
color = 'TechBlue'
elif colortrame == '0004':
color = 'CozyGrey'
elif colortrame == '0005':
color = 'Wazabi'
elif colortrame == '0006':
color = 'Lagoon'
elif colortrame == '0007':
color = 'Softberry'
else:
color = 'No color'
if buttontrame == '01':
button = 'simple appui'
elif buttontrame == '02':
button = 'double appui'
elif buttontrame == '03':
button = 'appui long'
elif buttontrame == '04':
button = 'relachement'
elif buttontrame == '05':
buttontrame = '05'
button = 'triple appui'
elif buttontrame == '06':
buttontrame = '06'
button = 'quadruple appui'
elif buttontrame == '07':
buttontrame = '07'
button = 'quintuple appui'
else:
button = ''
action['color'] = color
action['battery'] = battery
action['button'] = button
action['buttonid'] = buttontrame[1:2]
return action
globals.COMPATIBILITY.append(Niu)
Thanks @Domsrx06
I have added a new decoder for the NodOn NIU buttons, and this is what it is publishing for your sample messages. So the clicks all look fine, the battery level also makes sense, and I hope you tested it with a Lagoon coloured NIU button
“servicedata”: “02599c37d90287a521520006635ab801” 1 short click
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"short click","color":"Lagoon","batt":99}
“servicedata”: “02599c37d90287a52152000663ee4b02” 1 double click
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"double click","color":"Lagoon","batt":99}
“servicedata”: “02599c37d90287a52152000660259003” 1 long press
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"long press","color":"Lagoon","batt":96}
“servicedata”: “02599c37d90287a521520006622b8104” button release
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"button release","color":"Lagoon","batt":98}
i also receive this which i am not able to associate to an action
“servicedata”: “02599c37d90287a5215200065f000004”
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"button release","color":"Lagoon","batt":95}
“servicedata”: “02599c37d90287a5215200065f95da03”
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"long press","color":"Lagoon","batt":95}
“servicedata”: “02599c37d90287a5215200065f4f2402”
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"double click","color":"Lagoon","batt":95}
“servicedata”: “02599c37d90287a521520006604e1201”
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"short click","color":"Lagoon","batt":96}
“servicedata”: “02599c37d90287a521520006625eb901”
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":"short click","color":"Lagoon","batt":98}
The button click options you haven’t tested are the triple, quadruple and quintuple click 
This decoder will then be released with a next update of Theengs Decoder and Theengs Gateway, with the latter then also having the possibility to set the ble_time_between_scans to a decimal, which should be set to 0.1 to catch any and all button clicks.
One thing I couldn’t find though is the battery type which goes into the NIU buttons. Can you tell me what kind it is, possibly a CR2032?
Let me know what you think about the above results.
Thanks
ADDENDUM: We have decided to change the button press publishing as integers, and unified the results with the Shelly button, so that all current and future buttons will have the same result integer for easy and consistent integration in any controller:
- 1 - Short click
- 2 - Double click
- 3 - Triple click
- 4 - Quadruple click
- 5 - Quintuple click
- 6-8 - n click
- 9 - Long press
- 10 - Button release
e.g.
{"brand":"NodOn","model":"NIU smart button","model_id":"NodOnNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":2,"color":"Lagoon","batt":99}
Hello
This looks all good !
GREAT thanks @DigiH
I will be able to continue to use those buttons instead of throwing them away (i have 5 buttons)
Eager to test it soon
Do you know when the new release will be available ?
Yes the batterie is a CR2032
and i have other button colors so i will able to test this as well
The integer format is ok even if the text format was easier in Jeedom as when the pressed button was detected and action launched via a Jeedom scenario, i was changing the button text value at the end of the scenario.
ex : button = “simple appui” (short click) detected > scenario launched > action (ex launch audio player) > writte (“event” for Jeedom) button text with “(simple appui)” (the initial value with brakets) > end of scenario.
Then another action on the button will change the text to another.
This allows me to run the scenario only once (even if there are other way to manage this in Jeedom) and to control that the scenario is properly ended.
Looking MQTT Explorer and the fact that the same bluetooth message is repeated several times with the same value : i will have to make sure to manage the pressed button only once in Jeedom and with interger format i will have to manage it another way…
Could you add another text field “action” with the action description as Short click etc…?
Thanks for the battery confirmation @Domsrx06
We decided for the integer format as it is generally easier to implement in automations and rules in any kind of controller.
While I understand that for some UI cases it might be quicker to spot written out states, this is usually and best left to each controller to apply such transformations. In openHAB, for example, I would just apply a map transformation file/definition like
1 = Single short click
2 = Double click
3 = Triple click
4 = Quadruple click
5 = Quintuple click
9 = Long press
10 = Button release
to any UI instance where I would want the written out states. As this is also often used to translate transform received states like open/closed etc. I’m sure Jeedom has a similar feature to implement this easily.
We could get a small update to Theengs Decoder soon, also to see if and how the update might be shown in the Plug-In or coming up otherwise in Jeedom with an update notification
Hi @Domsrx06
Did you get any notification or see any indication that there has been a new release Theengs Decoder?
Possibly this only happens for the actual Theengs Gateway.
You can try again to
pip install --upgrade TheengsDecoder
to get 1.7.2, then restart Theengs Gateway (Plug-In), and you should have your NodOn NIU buttons decoded.
Hello @DigiH
sorry for the black out : other prio
I am not sure if i should report below Jeedom inputs here or in the Jeedom community… let me know
I have updated my Jeedom Atlas (see below log) and TheengsDecoder is in version 1.7.2 now
jeedom@JeedomAtlas:~$ pip install --upgrade TheengsDecoder
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: TheengsDecoder in ./.local/lib/python3.9/site-pac kages (1.7.0)
Collecting TheengsDecoder
Downloading TheengsDecoder-1.7.2.tar.gz (297 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 297.5/297.5 kB 8.2 MB/s eta 0:00:00
Installing build dependencies ... done
Getting requirements to build wheel ... done
Installing backend dependencies ... done
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: TheengsDecoder
Building wheel for TheengsDecoder (pyproject.toml) ... done
Created wheel for TheengsDecoder: filename=TheengsDecoder-1.7.2-cp39-cp39-linux_aarch64.whl size=62425 sha256=b1e9b4b7472b734927fabbb2455e4b8019fd0 d3ecacdd606badfee8bf33a894a
Stored in directory: /home/jeedom/.cache/pip/wheels/86/7f/de/5c3f8b19135301ca975acfa54cee10e7fbaabc276c8cb4047b
Successfully built TheengsDecoder
Installing collected packages: TheengsDecoder
Attempting uninstall: TheengsDecoder
Found existing installation: TheengsDecoder 1.7.0
Uninstalling TheengsDecoder-1.7.0:
Successfully uninstalled TheengsDecoder-1.7.0
Successfully installed TheengsDecoder-1.7.2
But my Jeedom antenna remains 1.4.0
(not sure if we are talking about the same version …)
despite “Configurer le service et (re)démarrer” and Jeedom restart
In Jeedom MQTT Discovery (MQTTDiscovery)
the NIU is not in the “Equipements Découverts” but in the “Equipements inconnus”
And while forcing the Jeedom equipement creation from “Equipements inconnus” the configuration of device NIU is empty
Where the NoDom “TheengsDecoder” is supposed to be “integrated” ?
_ in the Jeedom MQTT broker
_ in the Jeedom Theengs Gateway (tgw) plugin (no Jeedom depedencies to relaunch)
_ in the Jeedom Theengs Bluetooth antenna ? I have “Configurer le service et (re)démarrer” the antenna, but should i delete and recreate an antenna to get the version 1.7.2 ?
_ in the Jeedom MQTT Discovery (MQTTDiscovery) plugin (i have relaunched this plugin depedencies)
PS : for @Mips could we have pip install --upgrade TheengsDecoder integrated in the Theengs Gateway (tgw) Configuration plugin section
or may be in the MQTT Discovery (MQTTDiscovery)
Who knows …
Hi @Domsrx06
That is the correct version for the Theengs Decoder library.
That is fine, as Theengs Gateway itself wasn’t updated, so the existing version 1.4.0 is the latest.
But the buttons should now be correctly recognised and decoded, for this one with
{"brand":"NodOn","model":"NIU smart button","model_id":"NODONNIU","type":"BTN","acts":true,"cont":true,"track":true,"button":1,"color":"Lagoon","batt":88}
Likely not decoded as Theengs Gateway 1.4.0 will actually need to be restarted to then correctly load the updated new version 1.7.2 of the Decoder library. I don’t know if and how this is best done in Jeedom, through the Plug-In, manually or some other way.
Or if the above Theengs Decoder update was not loaded correctly into the right virtual pip environment.
Once the buttons get decoded correctly they will then also be discovered right, without you having to specify anything manually really - just like your Nut.
Hello there,
I created an account here, will be easier to follow-up if we keep discussion on the same forum
the plugin install the theengsgateway package in a venv (with pipx) to doing an upgrade of theengs decoder system wide won’t help.
so if I understand correctly, when gateway 1.4 was out, theengs decoder was still in version 1.7.0 and now a version 1.7.2 exists and that’s the one @Domsrx06 needs?
@Domsrx06 could you please execute this command and show the result:
sudo /root/.local/pipx/venvs/theengsgateway/bin/python -m pip freeze
Hello Mips
That is what I was wondering, if a system wide update installation of Theengs Decoder would work with the Jeedom install in a specific venv.
That is correct. During the initial installation Theengs gateway installs its dependencies at their latest versions, like
• bluetooth-clocks - to synchronise the time on a daily basis for compatible BLE clocks
• bluetooth-numbers - for getting the company ID of compatible manufacturerdata broadcasts
and
• Theengs Decoder for the actual decoding of BLE advertising data
So if any of the dependencies are updated, like Theengs Decoder for example, is it possible to update just that library in the venv, and to then restart Gateway to be able to then use the updated library?
It’s a bit similar to when recently paho-mqtt was updated, which is also a dependency for Theengs Gateway, but which then actually caused issues when Gateway restarted with the new version
As this is usually very common with usual pip insyalls to just update any of the depndencies and then restarting ateway has the new updated library, I was wondering if and how this might also be possible with the Jeedom installation in a venv with pipx.