Domoticz

CurrentCost devices are now integrated as hardware device. CC owners can now test this new opportunity to get their CC device into Domoticz.

Thanks for the hint. Been running a python script for almost a year now. Now need to figure how to migrate that data to the new native counter ...

looking forward to seeing your script

JC38 wrote:CurrentCost devices are now integrated as hardware device. CC owners can now test this new opportunity to get their CC device into Domoticz.

ok, what steps should i take to test it ?

Just go to Setup/Hardware and add a new device without forgetting to specify the Serial port.

I've seen that the CurrentCost integration have been done by "JohnAdders". Don't find him in this forum with this name.
Hope he comes here...

John, is-it possible to add support for other devices monitored by the CC ?
Actually, only the sensor 0 (whole house) is logged however getting also the others in separate Domoticz devices would be interesting.
Another question : how often new values are inserted into Dz database ?

been using CC EnviR for 2 days with the native hardware support.
It seems to be counter only, not summing up daily kwh totals. Is there a way to change it?

No devices added when using CurrentCost Meter with LAN interface (i assume port should be 80)
In a log i just can see:

Maybe you could help John and make a git pull request with the code changes ?

I am sorry not to be aware at all with GitHub. Even if I know some very little things about coding, I don't know how to use these tools.
The only things I can do is testing and discussing about the approach for solving the problem.
Is it possible to ask John to come to this topic ?

JC38 wrote: Hope he comes here...

Only occationally, I should have tracked to see if it actually works in the wild.

JC38 wrote:John, is-it possible to add support for other devices monitored by the CC ?
Actually, only the sensor 0 (whole house) is logged however getting also the others in separate Domoticz devices would be interesting.

Almost certainly, I've got a CC-128 I think which only has basic output, if I can some real xml generated by other devices I can play with adding more things. Id' be good to see the xml with as many different numbers of devices and types connected as possible.

JC38 wrote: Another question : how often new values are inserted into Dz database ?

Seems to be every time the value change and it's sampled every few seconds. Can smooth it if required

Rene wrote:Also does not keep track of kwh history so far.

The history would be useful, was probably going to add this by integrating the Watt figures eventually just like in asjmcguire's script.

rostyk wrote:No devices added when using CurrentCost Meter with LAN interface (i assume port should be 80)
In a log i just can see:

Code: Select all

 CurrentCost Smart Meter: connected to: 192.168.1.xxx:80

The LAN interface requires a serial to lan converter somewhere else probably with a different port, more than likely you just want the plain USB and get the right serial port.

John

JohnAdders wrote: Almost certainly, I've got a CC-128 I think which only has basic output, if I can some real xml generated by other devices I can play with adding more things. Id' be good to see the xml with as many different numbers of devices and types connected as possible.

John, thank you for coming here, and thank you for your job.
You will find as an attachment a zip file containing the xml raw data captured through the COM port.
As you will see, if you want to manage a CC with multiple devices (sensors) you will have to change the settings to ask people for the index (sensor id) of each one. And you also have to create a Domoticz device (type usage / subtype electric) per sensor.
Regarding the temperature, it's useless to upload it again when reading a sensor which id > 0. And even if you upload a new tmpr value each time you get a sensor 0 record, I think this is too much. My script was recording tmpr each time a value was received, and I think it explains why my database size was growing so fast.
I think updating the temperature only once per 10 values received per sensor with id0 is enough

JohnAdders wrote: Seems to be every time the value change and it's sampled every few seconds. Can smooth it if required

Rene wrote:Also does not keep track of kwh history so far.

The history would be useful, was probably going to add this by integrating the Watt figures eventually just like in asjmcguire's script.

John, I think the CC128 is transmetting its data through a "queue", the day and time pushed are not necessarly the same when it is decrypted by the client (Domoticz). And I don't think you are recording the date/time value from the CC, but the Domoticz timestamp.
In case you are logging the "Real-Time Output" watt values from the CC128, it's not a problem, because you are nearly the real time. And in fact, this is the best method, as the CC can easily be out of time (no daylight timesaving support, no ntp synchronization).
But when you will get the kwr records from the CC128, I can't see how to record these values into Domoticz with the good date/time. These kwh records are pushed as " History Output" and their date/time are the date/time when the value is pushed, not the value when the mesure occured.

JohnAdders wrote: The LAN interface requires a serial to lan converter somewhere else probably with a different port, more than likely you just want the plain USB and get the right serial port.

John

Hi,

just to confirm - do I understand correctly that the LAN interface option is not meant to be working with CurrenCost Bridge (available for EnviR at least)? But the USB option should work just by hooking the unit (EnviR in my case) to the Pi running Domoticz?

Nautilus wrote: just to confirm - do I understand correctly that the LAN interface option is not meant to be working with CurrenCost Bridge (available for EnviR at least)? But the USB option should work just by hooking the unit (EnviR in my case) to the Pi running Domoticz?

Correct

John

JC38 wrote: In case you are logging the "Real-Time Output" watt values from the CC128, it's not a problem, because you are nearly the real time. And in fact, this is the best method, as the CC can easily be out of time (no daylight timesaving support, no ntp synchronization).

I'm using the real time, agree that I shouldn't trust the timestamps which is why I haven't done anything with the history yet. Haven't played for a while but will check what the discrepancy between integrating the real time and the history is.

John

JC38 wrote: As you will see, if you want to manage a CC with multiple devices (sensors) you will have to change the settings to ask people for the index (sensor id) of each one. And you also have to create a Domoticz device (type usage / subtype electric) per sensor.

I think I can automatically create new indexes when I see the sensor xml. Will have a look tomorrow.

JC38 wrote: Regarding the temperature, it's useless to upload it again when reading a sensor which id > 0. And even if you upload a new tmpr value each time you get a sensor 0 record, I think this is too much. My script was recording tmpr each time a value was received, and I think it explains why my database size was growing so fast.
I think updating the temperature only once per 10 values received per sensor with id0 is enough

The updates are every 6 seconds, do you think it's worth averaging every 10 for all readings to thottle to once a minute for the power as well?

John

@JC38

Are you able to try this code out? I've added code to support multiple meters and throttle the temp.

https://github.com/JohnAdders/domoticz.git

branch currentcost

John

JohnAdders wrote: The updates are every 6 seconds, do you think it's worth averaging every 10 for all readings to thottle to once a minute for the power as well?

John

John, for my point of view you can keep each watt value you catch into the xml. In my opinion only the temperature sensor doesnt need to be updated with each record. 1 value par min = 1440 values/day.... Even a Oregon sensor doesn't send so many data. Once per 5 minutes would be enough. Or even better, send a new value for the tempr only if it's diffrent from the previous one