Yes, it’ll be intense, but every 60 seconds.
We should find a way to warn the user if the device is detected. Because typically there is a lot of information from this device that isn’t relevant to home automation; for example, in @Albenss’s screenshot, the ISOUSC expose never changes value.
Or maybe the solution is to identify those features and « ban » them
Indeed!
Hello,
On my side I requested a switch of my Linky to « Standard » mode with EDF (you just need to make the request via the modification
@VonOx I saw that you asked me for a review on the PR to support the Lixee TIC, cool if you were able to make progress 
Can you tell me more about the PR here?
Yes
No because I configured the device on the z2m side (I’m anticipating it’s not possible to do it on the Gladys side)
No unfortunately, I’m building it right away to have it tested.
Ok, so there are 2 major points to resolve before we can go to production.
The poll is set to 60 seconds by default on the z2m side.
On my side I had paired my device with an older firmware and on zigbee2mqtt dev to start the PR on the Gladys side.
The standard doesn’t cause any particular problem.
The only thing the user has to do is whitelist what they want from their meter (it depends on the weather and the captain’s age)
I really don’t see what we can do.
On the other hand other solutions ingest these data without any problem (HA / SQLite) so there might be something
So basically, if I understand correctly, the Z2M integration ingests a large volume of data every 60 seconds? (at peak)
Do you have numbers for the volume ingested by default?
The Z2M integration could also do some throttling since it’s a big spike, and distribute the events more evenly over time. We receive everything via MQTT; nothing forces us to process everything in the nanosecond.
Instead of sending 1000 events (I don’t know) in one burst, we can add a bit of delay between each event, to give Node.js time to breathe.
Don’t forget Node.js is a single-threaded technology that runs around an « event loop » (Node.js — The Node.js Event Loop), and that event loop can be blocked by synchronous operations that take too long. Ideally, that event loop should run continuously and never be blocked.
See if in the Z2M integration (or in the core) there isn’t a synchronous block that’s a bit too big which leads to event loop blocks and gives users the impression of a freeze.
To debug this kind of issue, there are libraries that exist (to be used only locally for testing):
Roughly (I didn’t count :D)
The device exposes the following by default:
ADCO, BASE, OPTARIF, ISOUSC, HCHC, HCHP, BBRHCJW, BBRHPJW, BBRHCJR, BBRHPJR, IINST, IINST2, IINST3, IMAX, IMAX2, IMAX3, PMAX, PAPP, PTEC, DEMAIN, HHPHC, PPOT, PEJP, ADPS, ADIR1, ADIR2, ADIR3, LTARF, NTARF, VTIC, DATE, EASF07, EASF08, EASF09, EASF10, EASD01, EASD02, EASD03, EASD04, EAIT, ERQ1, ERQ2, ERQ3, ERQ4, URMS1, URMS2, URMS3, STGE, PCOUP, SINSTI, SMAXIN, SMAXIN-1, CCASN, CCASN-1, CCAIN, CCAIN-1, UMOY1, UMOY2, UMOY3, SINSTS2, SINSTS3, SMAXN2, SMAXN3, SMAXN-1, SMAXN2-1, SMAXN3-1, MSG1, MSG2, PRM, DPM1, FPM1, DPM2, FPM2, DPM3, FPM3, RELAIS, NJOURF, NJOURF+1, PJOURF+1, PPOINTE1, linkquality
80 features
By setting its contract type it removes a large portion of them (there is now an auto mode)
Also, if there are too many unnecessary exposed items you can whitelist
Which gives me 7 features
For those motivated to test, I’ve built a test image
vonox/gladys:lixee
Ok!
I’m happy for you to take a look at the blocked event loop then 
I’m happy to help if you need me
OK do you want me to revert to my initial config? The infrastructure will take a hit.
Just tell me where I should put the function blocked(), I thought it was a wrapper but it’s not.
You put blocked() anywhere in the code (really anywhere); as long as it’s executed once it will listen continuously and will tell you if the event loop is blocked — and, most importantly, where it’s blocked!
So, for example, putting it here when Gladys starts up isn’t a bad idea:
( To remove afterwards of course, it’s just for debugging right now)
I received the lixee module but I still can’t see it on my network. The meter is about 20 m from my router.
I tried moving a Hue lamp closer but for now it’s the same.
As soon as I find it, I’ll let you know.
It’s spamming quite a bit on startup, I haven’t reset the config to defaults on the z2m (Zigbee2MQTT) side yet
But I have this coming back regularly: (every 30/40 seconds)
Blocked for 36.14090771484375ms, operation started here: [
' at Socket.connect (net.js:970:7)',
' at Object.connect (net.js:201:17)',
' at Object.streamBuilder (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/connect/tcp.js:18:14)',
' at MqttClient.wrapper [as streamBuilder] (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/connect/index.js:154:36)',
' at MqttClient._setupStream (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:298:22)',
' at new MqttClient (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:277:8)',
' at Object.connect (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/connect/index.js:156:16)',
' at Zigbee2mqttManager.connect (/src/server/services/zigbee2mqtt/lib/connect.js:16:40)',
' at Zigbee2mqttManager.init (/src/server/services/zigbee2mqtt/lib/init.js:88:18)',
' at async Object.start (/src/server/services/zigbee2mqtt/index.js:17:5)',
' at async Service.start (/src/server/lib/service/service.start.js:33:7)'
]
This lines up with a z2m device publishing new data
So in my opinion, a verbose device is screwing everything up
[quote=« VonOx, post:76, topic:6061 »]
But I
Not sure I understood what you want to do, do you want me to flood a z2 device? Knowing that I can’t create fake devices (maybe manually in the DB), I’d prefer not to mess up my production.
No, just go into
Besides, in this case it’s a small project that will benefit the entire Z2M integration.