Hi Olivier,
It seems you have an electricity meter with the ICC evolution. Can you try to replace every cbemm_base_electricitymeter by cbemm_evolution_icc_base_electricitymeter?
You can also test the auto discovery feature of the binding, it should auto detect your meter configuration.
Olivier
Hi Olivier,
Thank you for your quick reply. I first tested the replacement of 'cbemm_base_electricitymeterbycbemm_evolution_icc_base_electricitymeter` in my thing and item definition but it did not change the log file so I removed both and used the autodetect feature. I get the following resut in the attached picture.
So I cannot link Items. It seems that, somehow, the stream received from the serial port does not have the expected format.
Olivier
Hi Olivier, After many tests, modifications and Openhab restarts, it works !!!
Thank you again for the plugin and your help.
Kind regards
Good news! Have you done it with textual config or with paper ui?
Is your detected electricity meter a cbemm_evolution_icc_base_electricitymeter?
Hi Olivier,
I think there was a problem in one of my config files. I rewrote them from scratch using a cbemm_evolution_icc_base_electricitymeter and it worked.
Thanks again for your help.
Hello Olivier,
Thanks for your teleinfo binding.
If have installed it yesterday on a Raspberry pi3 with Openhab 3.0.1 and I’m facing some issues:
11:47:21.404 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'teleinfo:serialcontroller:ceda2af6a9' changed from UNKNOWN: Serial Error: Retry in progress... to ONLINE
11:47:21.407 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'teleinfo:cbetm_tempo_electricitymeter:ceda2af6a9:0419765xxxxx' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
11:47:21.857 [WARN ] [internal.serial.TeleinfoReceiveThread] - Got invalid frame. Detail: "The groupLine '' is incomplete"
11:47:21.857 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
org.openhab.binding.teleinfo.internal.reader.io.serialport.InvalidFrameException: The groupLine '' is incomplete
at org.openhab.binding.teleinfo.internal.reader.io.TeleinfoInputStream$1.call(TeleinfoInputStream.java:211) ~[?:?]
at org.openhab.binding.teleinfo.internal.reader.io.TeleinfoInputStream$1.call(TeleinfoInputStream.java:1) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
11:47:26.904 [WARN ] [internal.serial.TeleinfoReceiveThread] - Got timeout during frame reading
java.util.concurrent.TimeoutException: null
at java.util.concurrent.FutureTask.get(FutureTask.java:204) ~[?:?]
at org.openhab.binding.teleinfo.internal.reader.io.TeleinfoInputStream.readNextFrame(TeleinfoInputStream.java:266) ~[bundleFile:?]
at org.openhab.binding.teleinfo.internal.serial.TeleinfoReceiveThread.run(TeleinfoReceiveThread.java:65) [bundleFile:?]
11:47:26.908 [WARN ] [internal.serial.TeleinfoReceiveThread] - Retry in progress. Next retry in 60 seconds...
11:47:26.914 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'teleinfo:serialcontroller:ceda2af6a9' changed from ONLINE to UNKNOWN: Serial Error: Retry in progress...
11:47:26.917 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'teleinfo:cbetm_tempo_electricitymeter:ceda2af6a9:0419765xxxxx' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Controller is offline
The meter with its ADCO and tarif option has been correctly identified during setup.
I’m using the Téléinfo 1 compteur USB from Cartelectronic
My Linky meter is Landis+Gyr with the TIC mode to “History”
Can you please help me ?
Kind regards,
Jacques
Hi Jacques,
You must also thanks @nokyyz who is the main contributor of this binding.
We had a very strict timeout policy in the initial version (which is in openhab 3.0). In openhab 3.1 these timeouts will be removed so your issues should be solved.
Maybe you can try to disable and enable again the bridge (serial controller thing) until success.
Or you can try the new version of the binding (put this jar in your addons directory). The 3.1.0 version of the teleinfo binding is compatible with openhab 3.0.1.
Hi Olivier, hi Nicolas,
Many thanks to Nicolas (@nokyyz) for this binding.
Finally after some delay, the binding begin to work correctly 
To have more teleinfo available, I asked EDF/Enedis to switch the TIC mode to standard. This was effective during the night and this morning it was no more working. I tried to uninstall the configurated teleinfo and reinstall everything with the 3.0.1 and 3.1 bindings but both were unsuccessfully 
Currently I reinstalled the 3.0.1 version but my meter is not detected during the scan phase and the error message is back:
10:06:32.218 [WARN ] [internal.serial.TeleinfoReceiveThread] - Got timeout during frame reading
java.util.concurrent.TimeoutException: null
at java.util.concurrent.FutureTask.get(FutureTask.java:204) ~[?:?]
at org.openhab.binding.teleinfo.internal.reader.io.TeleinfoInputStream.readNextFrame(TeleinfoInputStream.java:187) ~[bundleFile:?]
at org.openhab.binding.teleinfo.internal.serial.TeleinfoReceiveThread.run(TeleinfoReceiveThread.java:65) [bundleFile:?]
10:06:32.225 [WARN ] [internal.serial.TeleinfoReceiveThread] - Retry in progress. Next retry in 60 seconds...
I will wait to see if the problem will fix by itself in some time but…
If you have some more idea?
Can you make a dump of your teleinfo data? cat /dev/ttyUSBX > teleinfo.data (replacing /dev/ttyUSBX by your usb device path) must do the job.
Hi Olivier,
I just send you the file in MP.
Thanks for your help.
Hi Olivier,
I checked the port parameters and saw it was in 1200 bauds. Standard mode sends data in 9600 bauds.
Is the baudrate not managed by the binding? How to select the baudrate to keep it correct after a reboot?
This change does not fix the issue which is always the same.
It seems the baudrate is regularly reset to 1200 bauds. Is it done by the teleinfo binding?
It should be fine if we could specify the baudrate when specifying the port to be used.
The baudrate defined by the binding is 1200. This is specified in the (old?) teleinfo protocol.
Currently the binding doesn’t support the standard mode of linky telemeter. According to this blog you must use the historical mode.
Maybe you can fill an issue to ask support for the standard mode. But I don’t have a linky telemeter so I could not implement that without help.
Hi!
I’m not sure to understand why the Teleinfo Binding does only support historical mode on Linky telemeters…
According to the binding documentation, it seems to support standard mode. But standard mode only comes with a Linky telemeter! So, I’m totally confused…
Are the source files available? It is maybe not that difficult to adapt it to Linky standard mode…
Thanks,
Frédéric
Hi Frédéric!
The Teleinfo Binding does support standard mode on Linky telemeters!
See
and
Please feel free to improve the binding documentation (by submitting a PR on github) if you find it confusing!
Olivier
Thanks for you answer!
So, the version automatically installed using the GUI is not the latest one, and I need to install it manually?
How do I do that?
About the documentation, on the binding page, the last sentence says it is not compatible with Linky standard mode, but if this is not the last version of the binding, it makes sens…
PS: with my install, the binding seems to communicate, but I only get the corrupted frame counter channel…
Standard Mode was merged in main branch in december 2021 so if you use a posterior version you can use the version installed using the GUI.
That’s a mistake! I forgot to delete this sentence, sorry for that! Can you submit a PR or an issue on github?
There are two steps to configure the teleinfo binding:
How do I trigger the auto-discovery feature? I thinkthis part is not working for me…
I created an issue for the documentation…