I’ve been quite absent from Gladys for a few months, but I would like to resume the integration work of the enocean protocol on Gladys 4.
However, the enocean-js module doesn’t really suit me, the guy who develops it does a great job but he’s alone, there’s no documentation and I’m struggling a lot…
Since I do a lot of Python at work, I’m looking at Python and I find things I would like to experiment with.
But in this case, it would rather be in the form of a remote module based on MQTT exchanges.
What would be the right approach on the Gladys side? Should I develop a Gladys integration in charge of the discussion via MQTT with Python/Enocean or is there a standard interface for this?
I admit that I haven’t really looked into V4 yet, but it’s time to get started
I made your post public so that everyone can see it
So three options:
In itself, you could very well call Python code from Gladys and keep this integration in Gladys. After all, if it’s really a Python program running permanently, that’s not great.
You can take inspiration from what has been done on the zigbee2mqtt module, which is a service whose work is done by a Docker container that communicates with Gladys via MQTT. You would therefore need to develop the remote service, create a UI in Gladys to control everything, and develop an MQTT API between the two so that they can communicate. After that, in the zigbee2mqtt module, this was done because zigbee2mqtt is an external project that we do not control and which has done a great job of converting zigbee messages from many integrations into MQTT.
Dive into the enocean-js code and make a native integration in Gladys.. I went to look at the enocean-js repository, I expected an abandoned project and frankly it looks solid and well designed. V4 is not V3, the goal of V4 is to design a public software that is easy to use and works « out of the box ». A native integration when possible, it changes everything.
You can take inspiration from other projects that use enocean-js like node-red-contrib-enocean, the code is readable and I think we could quite simply transpose that into Gladys
I’ve finally started developing an Enocean integration.
After a few hours of banging my head to understand how V4 works, I have a service that starts and connects to my USB dongle
I’m going to try to integrate the enocean-js module directly into gladys, which is a bit of a challenge, but it’s the ability to support all the existing equipment variety… so I’ll start by seeing how to support simple sensors (like temperature, motion, etc.) and then we’ll go step by step.
What I can do is push my branch to git and maybe you could tell me if it’s « Gladys compliant » what I’ve started. I started from the Z-wave integration.
A question about device management and their features.
When looking at the Xiaomi and Zwave integrations, I get the impression that when a value is received from a sensor, a message is sent to Gladys with the type EVENTS.DEVICE.NEW_STATE by systematically reconstructing the device object?
I thought I should first register the known / paired / registered / scanned devices before being able to send / receive data.
No, you just need to emit an event with the external_id of the device (the unique identifier on the EnOcean side) and the new state.
Example in the case of the Xiaomi service:
That’s exactly what you need to do, take inspiration from the Z-Wave service for example. There are 2 tabs: 1 tab for devices that are already connected to Gladys, and a tab to connect new Z-Wave devices to Gladys.
If there’s anything else you don’t understand, don’t hesitate
It’s the addDevice.js function that emits an event with the new device in the payload. But I don’t understand how gladys registers this device in the db..? I don’t see the call to gladys.device.create()
Only the front seems to listen to the XIAOMI.NEW_DEVICE event and if I understand correctly, just to reload the list of devices?
There are still things I don’t understand
For the moment, in what I’ve written, I call gladys.device.create() myself, I don’t go through an event.
I would appreciate some clarification here
Edit: Ok I just saw action.js on Xiaomi … I understand better… I will take inspiration from it!
I’m finally trying to get back to work on Gladys… this time it’s going to happen
Currently, I’m doing development at work, so in the evening I struggle to do more development… except that V3 is running out of steam… I have a lot of Enocean equipment that I’m not using, and it’s frustrating…
I even considered testing Jeedom… no but seriously…
So I gathered my courage and just got my hands back in the gears!
I resumed the development of the Enocean integration, and it’s starting to look like something, I’m more comfortable with the code structure.
I managed to add devices and see them correctly in the dashboard.
I still need to:
manage more equipment profiles.
handle messages when a device sends something
send a message to a device
write the tests
I have good hope to have something functional quickly!
And after that, I have no more integration to do on what I had done in V3 that I use daily (essential to migrate and turn off V3 at home)
Here’s a bit of news, I hope I won’t fall into a black hole after this email
I’ve made good progress, I’m able to retrieve values from several types of equipment.
I’m working on equipment that can currently receive orders.
I still have tests to write as well.
I’m reaching out to Enocean device owners, could you let me know what equipment and EEP profiles you have at home?
Because the challenge will be to support as many devices as possible.
For information, I’m based on the enocean-js module where you can see the supported profiles here: https://enocean-js.github.io/enocean-js
Hello, I have been following your project for a long time now. I think that yes, the switches are also important, as well as micro modules like Nodon for lighting and roller shutters, which are the most important. Personally, I use Eltako equipment, which is quite comprehensive in terms of EnOcean. By the way, I will try your program when I understand how to install it lol.
Currently I have an issue making the wall switches (d2-01) work, in fact I manage to control one, but if I have several, they are all paired together, so not practical.
I haven’t been able to progress further for the moment.
Hey some news… it’s definitely complicated to free up time
These days, I’ve motivated myself and managed to get my switches working correctly with a D2-01-00 profile.
I don’t have a module for the roller shutters @eric2-6 if you can give me a link to what you have so I can see how to integrate them.
As a result, I started looking into writing the tests, but I’m encountering problems @pierre-gilles
I haven’t installed the zwave lib, and eslint is yelling at me about the import in the z-wave integration:
gladys-server@ pretest /home/jp/Gladys4/Gladys/server
> npm run eslint
> gladys-server@ eslint /home/jp/Gladys4/Gladys/server
> eslint .
/home/jp/Gladys4/Gladys/server/services/zwave/index.js
7:25 error Unable to resolve path to module 'openzwave-shared' import/no-unresolved
So to bypass, I roughly removed the pretest from the npm scripts. (well I did want to install it but you also have to install the binary and I got errors at make .. so I wanted to keep it simple)
But then, I get this error:
> gladys-server@ test /home/jp/Gladys4/Gladys/server
> cross-env NODE_ENV=test ./node_modules/mocha/bin/mocha --recursive ./test/bootstrap.test.js "./test/**/*.test.js" --exit
/home/jp/Gladys4/Gladys/server/services/mqtt/node_modules/mqtt/mqtt.js:1
(function (exports, require, module, __filename, __dirname) { #!/usr/bin/env node
^
SyntaxError: Invalid or unexpected token
at new Script (vm.js:100:7)
Yes, I’ve resolved it. I had to take a step back and dig into it for the n-th time to understand how it works. The thing is, the guy maintaining the library hasn’t responded in 6 or 7 months
The idea is that I’ll run it at my place for some time before pushing a PR. I don’t know how to share my code if others want to test it. I saw a post where you can create images via integration…
Ah And isn’t there anything more recent in terms of the library? It’s not great for the future of the integration if the dependency is no longer maintained ^^