-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make access to bridge easier #1
Comments
Thanks for the nice comment. This documentation is based on the Norwegian version of the Tibber Pulse that connects directly to a meter using MBUS. It is not using the IR reader and the Tibber Pulse IR Bridge as it seems the guide you linked to is using. Since the power supplied from the meters is very low, I dont think tibber added the ability to keep the webserver running on the firmwares running on our version of the Pulse. I will check it later, as I havent actually checked if there are any other pages accesible during the setup of the Pulse. There might be some kind of hidden page for configuring it. Anyways, thank you! |
I should also specify the version of Pulse this is using, as I didnt know they were supplying other versions of it in other countries. Here in Norway the electricity company were forced to switch to AMS meters that had MBUS. |
@CONSULitAS Thanks for pointing that out. and thanks @micw for the blog post! I have found that this makes it much easier to get the data that the Pulse IR sends. Now we just need to find an easy way to decrypt the data. |
@JMyrng I'm guessing they send the data in binary? I dont have access to a Pulse IR so I cant really help. On the Norwegian models they just retransmit the OBIS information the Meter spits out over MBUS. You can see the lists sent via this pdf https://www.nek.no/wp-content/uploads/2018/11/Kaifa-KFM_001.pdf. You might also want to take a look at https://github.com/toreamun/amshan-homeassistant which implements the OBIS list decoders for the NO version of the Pulse. You never know, they might be lazy and just encode it like an OBIS list |
Hey, glad that my post was of use and I'm impressed how fast it was discovered ^^ Actually I got my pulse running (by manually pairing it with the bridge) while still waiting for tibber to solve my update problem (need to update my blog post). Meanwhile I also discovered the "data.json" endpoint. It contains a complete SML message including pre- and suffix. The main drawback is that it requires polling, so a receiver would need to sync intervals with the meter. Actually the "data" page of a node on the bridge does exactly this - polling every second. |
Fore reference, here's a data package, hex encoded (it comes in binary from the endpoint):
|
Any idea on how to decode that sml message? |
Have a look at https://www.openmuc.org/de/sml/. |
@MSkjel Great documentation. I have an additional MBus adapter on my meter so that I can read the data there. But having access to the pulse data stream is great since it's updating way more often. I will link to it in my post.
|
@micw |
Ich bastel gerade was. Wird eine kleine Java-Anwendung (auch als Docker-Container), welche die Pulse Bridge auslesen und das Ergebnis ausgeben kann. Mein Plan:
Ich schreibe hier, wenn was testbares da ist. Aktuell bin ich am SML parsen. |
Here is my tool: https://github.com/micw/tibber-pulse-reader Example publish:
|
Will test it next week 👍 |
I wrote a small Python script that also pulls the data from |
If you are able to build hardware, then yes! It is an easier way to get the data. I have an ESP, IR-Transistor an get the raw data stream from #1 (comment). I have written a manual decoder for SML but use also Tasmota with SML decoder. But I am able to connect electronic parts with an esp and breadboard. Schematic as sketch: https://chaos.social/@e_es/110202823482139258 |
I made a circuit for this: evcc-io/evcc#7070 (comment) Edit: tried the same with a single PNP but it was unreliable and I could not figure out why. So I switched back to my initial circuit that uses 2 NPN. Edit2: Link to the circuit and PCB: https://oshwlab.com/mwyraz/ir-meter-head-simple_copy_copy |
Very nice OS Hardware! The Question is now, if it is suitable for malloy139. |
Actually it is the easiest way to get the data in the frequency the meter sends it, without interfering to much with tibber's hardware. |
I already have an optical reader for my meter and would like to use this to report hourly readings instead of the Pulse – the meter I have is not supported as it seems to be using IEC 1107. How does Pulse report the readings? |
Do you mean "does Tibber support this"? AFAIK only for Norway, there is an API to auto-report this. You can use the normal APP api to report hourly readings but you would still be in the "monthly" tariff, so it's just a replacement for monthly manual reading. I have created https://github.com/micw/tibber-meter-uploader for this before I got my Pulse ;-) |
Right, but how do they distinguish? Could I buy a Pulse (and thereby "connect" it with my account), simply to enable that part of the API and make them accept the readings? |
Pulse uses MQTT to AWS instead of the API. But would not help, the hourly tariff requires 10s values (or so) otherwise it will auto-switch back to monthly. |
The Tibber bridge sends OBIS data to the MQTT topic then? |
It does send the OBIS data, but it does also include some data before the raw OBIS list. I'll see if I cant dump a list or two for you. It does also send some status updates as JSON to the Tibber MQTT server, which includes a serial number though. I dont know if what you want to achieve is possible, depends on how they validate the data server-side. All pulses sold in norway use the serial number when adding the pulse to the tibber app. |
Thanks very much, that would be awesome! |
I think you need to pair your pulse first to get the client certificate required to communicate with their mqtt broker (some AWS IoT platform). Then you need to figure out what exact data you need to send. |
This file contains the JSON which is sent maybe every 2-5 minutes to the tibber MQTT server, as well as OBIS List 1 and List 2. |
Cool, thanks very much! So the serial number in your json is the "ID" field and the 12-digit hex string? Both json and binary OBIS data are sent to the same topic /tibber-bridge/xxx/publish in separate publish() calls or appended binary to json? UPDATE: tried the local mqtt server (simple ip address, no credentials, no TLS) but it fails: And just a warning for everyone: once you've deleted the keys it seems like you cannot put them back in because of some buffer overflow. Here is the request I intercepted: And the reply:
Oops. Same garbage shows up in params.json |
The JSON is sent separately from the OBIS Lists, but to the same topic. Not sure about the frequency of these reports, but it shouldnt have to be often. The pulse works even without them, but it will show as offline in the app (but the power consumption is still updated). Im not sure what data is actuallt included in the raw OBIS datastream. It seems there is some data appended to the OBIS Lists. Keep in mind that the binary file I linked contains two different OBIS Lists. List 1 and List 2, in that order. They are sent individually. |
Would you agree to share your python script? All the best, |
Sure, it's far from perfect but it works for me. I run it in a screen session.
|
Did you get your local MQTT running? I'm trying to archieve the same - but i can't get the tibber to connect to my local mqtt |
Hi, I was having a similar problem with my german Tibber Pulse+Bridge. I did not manage to really emtpy the "cert"-entries. I recently bought a new Tibber Pulse+Bridge and activated it without using the tibber app (via AP and Webfrontend). Long story short: this time it worked. Either it depends on the firmware version or my guess is that only if the cert fields are really empty the bridge can connect to the local mqtt-server. Otherwise it tries to use mqtts and fails. I just now found out how to really clear a parameter (in the webfrontend some abbreviated field-name remains). When I open up the console and enter for example Perhaps you can try this. Another approach I would have tried if the above had not worked for me:
Kind regards |
Yes, that worked! It is now mqtt_status.connected=true |
And got some data
And on $aws/rules/ingest_tibber_bridge_data/tibber-bridge/xxx/publish/TJH01/3494545e84000/metric
|
a lot more data than expected. I hope to be able to simulate the pulse device - as i need a constant update rate of 1s which the tibber pulse does not provide to me... |
Yes, quite complex. There is also a number of other states besides "NODE_EVENT_METER_PROBING", especially at bootup. Also there is a separate metric for the Pulse IR node (same content as http://192.168.188.31/nodes/1/metrics). And I haven't seen data yet... Did you intercept any? |
Haven't tried it yet - due to lack of time... but it's on my todo list.... |
I've configured the pulse for the impulse interface (10000 pulses/kWh) and am flashing a LED at 10 Hz at it. This gives on The event messages stopped, only the metrics continue to be sent Now lets see if the app displays anything. Currently it says "no data" |
I have continued the data format discussion in a new issue #6 |
Hi,
a really great documentation! I really appreciate your work.
A guy recently posted this guide: https://blog.wyraz.de/allgemein/a-brief-analysis-of-the-tibber-pulse-bridge/
If you set the parameter „webserver_force_enable“ to true while in AP mode, you can connect to the bridge even while connected to your WiFi.
This makes your guide even easier, because no reset and reboot needed for reconfiguration.
Only connect to the fresh/reseted device with your phone/tablet, change the parameter and everything is quite easy.
The text was updated successfully, but these errors were encountered: