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.
Hello @Mips
commande introuvable
Votre Jeedom est dispo sur http://jeedomatlas.local ou sur :http://192.168.1.69
Last login: Fri Feb 23 17:04:24 2024 from 192.168.1.76
jeedom@JeedomAtlas:~$ sudo /root/.local/pipx/venvs/theengsgateway/bin/python -m pip freeze
[sudo] Mot de passe de jeedom :
sudo: /root/.local/pipx/venvs/theengsgateway/bin/python : commande introuvable
jeedom@JeedomAtlas:~$
is theengs gateway installed locally on the atlas?
yes locally installed
Bluetooth is with an external dongle on Jeedom Atlas USB external slot (not using the integrated Atlas Bluetooth capability)
Could you execute
sudo pipx list
jeedom@JeedomAtlas:~$ sudo pipx list
[sudo] Mot de passe de jeedom :
venvs are in /root/.local/share/pipx/venvs
apps are exposed on your $PATH at /root/.local/bin
manual pages are exposed at /root/.local/share/man
package theengsgateway 1.4.0, installed using Python 3.9.2
- TheengsGateway
ok then that’s the command to get versions number:
sudo /root/.local/share/pipx/venvs/theengsgateway/bin/python -m pip freeze
meanwhile i reproduce the situation (gateway 1.4 with decoder 1.7) to check what are the best options i could implement in the plugin
but not sure it worth over-designing something as this kind of situation sounds exceptional to me but maybe i’m wrong;
to unblock you immediatly you can already uninstall (the red button) and install it again immediately (do not create a new equipment), that will install last version of the gateway and all dependencies, decoder included.
@DigiH could you estimate if it happens often than the decoder is updated but not the gateway or if most of the time you create a new version of the gateway if need be?
depending the answer I would manage both packages more independently while today the decode is “just” a dependency of the gateway (like few others)
Well, honestly, normally not that often, but especially now with several Jeedom users switching from the BLEA Plug-in to the TGW Plug-in, and still some devices missing in Theengs gateway which were present in BLEA, like the NodOn NIU buttons, it would be good for an easy way for jeedom users to be able to update Theengs Decoder separately.
Like with @Domsrx06, we do not even know yet if the new decoder does work fine with his NIU buttons yet in real circumstances - they should, but a proper confirmation would be best.
Plus the fact that he could then use the new decoder as well before a new Theengs Gateway version is being released.
I just assume the same happening with other devices from BLEA when we try to integrate them into TGW when Jeedom users request it.
I suppose a complete de-installation of TGW and then reinstalling it anew - which would then get the new Theengs Decoder version as its dependency, like now any fresh installation of TGW does - will have the same effect, but might be even more complex or possibly causing other issues?!?
“Désinstaller l’antenne”
“Installer l’antenne”
“(Re)Démarrer le service”
tgw_1200_update.txt
[2024-02-23 17:37:35] *************************************
[2024-02-23 17:37:35] * Launch install of dependencies *
[2024-02-23 17:37:35] *************************************
[2024-02-23 17:37:36] Reading package lists...
[2024-02-23 17:37:37] Building dependency tree...
[2024-02-23 17:37:37] Reading state information...
[2024-02-23 17:37:38] curl is already the newest version (7.74.0-1.3+deb11u11).
[2024-02-23 17:37:38] 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2 100 2 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
[2024-02-23 17:37:39] Get:1 http://security.debian.org bullseye-security InRelease [48.4 kB]
[2024-02-23 17:37:39] Hit:2 http://deb.debian.org/debian bullseye InRelease
[2024-02-23 17:37:39] Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
[2024-02-23 17:37:39] Get:4 http://deb.debian.org/debian bullseye-backports InRelease [49.0 kB]
[2024-02-23 17:37:39] Hit:5 https://deb.nodesource.com/node_18.x nodistro InRelease
[2024-02-23 17:37:40] Hit:6 http://armbian.systemonachip.net/apt buster InRelease
[2024-02-23 17:37:40] Hit:7 https://packagecloud.io/ookla/speedtest-cli/debian bullseye InRelease
[2024-02-23 17:37:41] Fetched 141 kB in 3s (53.5 kB/s)
[2024-02-23 17:37:45] Reading package lists...
[2024-02-23 17:37:45] ***************************************
[2024-02-23 17:37:45] * Install dependencies, venv & pipx *
[2024-02-23 17:37:45] ***************************************
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2 100 2 0 0 62 0 --:--:-- --:--:-- --:--:-- 64
[2024-02-23 17:37:45] Reading package lists...
[2024-02-23 17:37:46] Building dependency tree...
[2024-02-23 17:37:46] Reading state information...
[2024-02-23 17:37:47] logrotate is already the newest version (3.18.0-2+deb11u2).
[2024-02-23 17:37:47] python3-pip is already the newest version (20.3.4-4+deb11u1).
[2024-02-23 17:37:47] python3 is already the newest version (3.9.2-3).
[2024-02-23 17:37:47] python3-venv is already the newest version (3.9.2-3).
[2024-02-23 17:37:47] 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 1037 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main arm64 bluez arm64 5.55-3.1+deb11u1 [1037 kB]
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:
Fetched 1037 kB in 0s (8060 kB/s)
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 67991 files and directories currently installed.)
Preparing to unpack .../bluez_5.55-3.1+deb11u1_arm64.deb ...
Unpacking bluez (5.55-3.1+deb11u1) over (5.55-3.1+deb11u1) ...
Setting up bluez (5.55-3.1+deb11u1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for dbus (1.12.28-0+deb11u1) ...
[2024-02-23 17:38:11] Version debian:11
[2024-02-23 17:38:11] Install pipx via pip
[2024-02-23 17:38:13] Requirement already satisfied: pipx in /usr/local/lib/python3.9/dist-packages (1.4.3)
[2024-02-23 17:38:13] Requirement already satisfied: argcomplete>=1.9.4 in /usr/local/lib/python3.9/dist-packages (from pipx) (3.2.2)
[2024-02-23 17:38:13] Requirement already satisfied: packaging>=20 in /usr/local/lib/python3.9/dist-packages (from pipx) (23.2)
[2024-02-23 17:38:13] Requirement already satisfied: platformdirs>=2.1 in /usr/local/lib/python3.9/dist-packages (from pipx) (4.2.0)
[2024-02-23 17:38:13] Requirement already satisfied: tomli in /usr/local/lib/python3.9/dist-packages (from pipx) (2.0.1)
[2024-02-23 17:38:13] Requirement already satisfied: userpath!=1.9.0,>=1.6 in /usr/local/lib/python3.9/dist-packages (from pipx) (1.9.1)
[2024-02-23 17:38:13] Requirement already satisfied: click in /usr/local/lib/python3.9/dist-packages (from userpath!=1.9.0,>=1.6->pipx) (8.1.7)
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
[2024-02-23 17:38:16] /root/.local/bin has been been added to PATH, but you need to open a new
[2024-02-23 17:38:16] terminal or re-login for this PATH change to take effect.
[2024-02-23 17:38:16]
[2024-02-23 17:38:16] You will need to open a new terminal or re-login for the PATH changes to take
[2024-02-23 17:38:16] effect.
[2024-02-23 17:38:16]
[2024-02-23 17:38:16] Otherwise pipx is ready to go! ✨ 🌟 ✨
[2024-02-23 17:38:16] ****************************
[2024-02-23 17:38:16] * Install TheengsGateway *
[2024-02-23 17:38:16] ****************************
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2 100 2 0 0 55 0 --:--:-- --:--:-- --:--:-- 57
creating virtual environment...
installing theengsgateway...
⚠️ Note: '/root/.local/bin' is not on your PATH environment variable. These
apps will not be globally accessible until your PATH is updated. Run `pipx
ensurepath` to automatically add it, or manually modify your PATH in your
shell's config file (i.e. ~/.bashrc).
done! ✨ 🌟 ✨
[2024-02-23 17:39:12] installed package theengsgateway 1.4.0, installed using Python 3.9.2
[2024-02-23 17:39:12] These apps are now globally available
[2024-02-23 17:39:12] - TheengsGateway
[2024-02-23 17:39:12] ***************************
[2024-02-23 17:39:12] * Install ended *
[2024-02-23 17:39:12] ***************************
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2 100 2 0 0 2 0 0:00:01 --:--:-- 0:00:01 2
100 2 100 2 0 0 2 0 0:00:01 --:--:-- 0:00:01 2
Restart Jeedom, same : FAIL
I could remove Theengs Antenna and Theengs Gateway (tgw) plugin and restart from crash : this is acceptable on a test environment : NOT in PROD
@Mips Please develop a depedencies “Relance” at Antenna level
exactly and that won’t cause any issue;
and it is easy: 2 buttons to click in the plugin.
the only drawback is that on small machine like pi0 it takes +/-1h to install
so the 2 options i’ve:
- do nothing, tell people to uninstall/install (2 clicks) but wait 1h if on pi0
- review the way I install the venv, to manage decoder & gateway separately; nothing really complicated, i see exactly what to do, i just need time.
thanks for your feedback
what does it means? be more specific please
and please provide detailed versions number (before and after the operation) with the command i gave above.
this is totally an acceptable solution as this has zero functional impact, only time needed depending the harware
but i think you completely misread my request, I never ask to uninstall the plugin:
so:
at your service my lord…
and useless to capture that part as it won’t be the place to be
we are not talking about the plugin but about one instance of theengs gateway, what i call an “antenna”; an “equipment” within jeedom
Thanks for your responses and looking into this. For me the main thing was to properly understand how TGW is installed and functioning with Jeedom. To then know how to be able to implement new devices into Decoder for any Jeedom user requests and how they might be able to verify them.
Time is fine if you’re looking into any way to make a separate management possible Thanks a lot.