I’m looking for some guidance on integrating IoTaWatt with InfluxDB 3 (Core) and wanted to check if anyone has this working, or if official support is planned.
My setup
IoTaWatt for power monitoring
InfluxDB 3 Core running on a local Linux server
Node-RED sitting in between (happy to keep IoTaWatt → Node-RED → Influx if that’s the recommended path)
What I’ve tried
From the InfluxDB 3 documentation, it suggests using the InfluxDB v1 compatibility approach and:
Setting the server as InfluxDB v1
Replacing the password field with the API token
However, when I paste the InfluxDB 3 token into the IoTaWatt configuration:
The Save button disappears
I’m guessing this might be due to:
Token length
Unsupported characters in the token
Or a UI validation limit in IoTaWatt
Questions
Is InfluxDB 3 (Core) supported or planned to be supported directly?
Are there known length or character limitations in the IoTaWatt password/token field?
Is the recommended approach to use Node-RED as a bridge (IoTaWatt → Node-RED → InfluxDB 3)?
If anyone has this working, I’d really appreciate any pointers or examples.
Thanks in advance — happy to test or provide logs if helpful.
Haven’t looked into influxDB3 but if it’s as simple as replacing the password with the API token, should be easy to accommodate that. If you tell me the format of the token, I can probably give you a hack to allow it as password.
I’ve taken the liberty of moving this PM to a topic as the response should be of general interest, especially to influxDB1 (and influxDB2) users.
I’ve read over the docs for influxDB3. It seems to be true that influxDB3 only requires changing the authorization from “Basic” to “Bearer”. That is included in a header and would be easy to change.
However:
While the write protocol remains identical, the support of influxQL is billed as transitional support and not guaranteed to be supported forever. I don’t know how they would be able to desupport something like that but then again they pushed influxDB2 on the community with the disastrous FLUX query.
So if I’m going to code up support for this third go-round, I would move to the native SQL query to resolve last post on startup. That will require a little work, but actually quite a bit cleaner. As I understand it influxQL is a compatibility layer on top of the SQL query anyway.
So bottom line is that it looks pretty doable. Right now I’m finishing up with @brettbeeson on his contributed PostgREST uploader which is essentially done, just testing and integration. After that, I’ll stand up an influxDB3 instance and add support.
Thank you for the quick response. I’m more than happy to wait for full support, as my setup has been offline for a while, and I fully agree that having SQL support is probably the right approach.
My setup is almost like a new one so I’m happy to be a tester on this . I’ve also just had batteries fitted to my solar system this week, so it has my focus again for a while.
