Release v2.0.0-dev10 - Bug? INA219 I2C 0x45 problem

[robatbentley]

Hi,
I've noticed this problem from when I first started using the Dev builds such as Release v2.0.0-dev08. When I configure my INA219 voltage and current measurement device (in a stack with three other INA devices - I2C addresses of 0x40, 0x41 and 0x44) with I2C address of 0x45, the measurements from all 4 devices read incorrectly. See attached screen-shots. If I deactivate the 0x45 device and reboot the node then the problem goes away.

Any chance someone can confirm this and provide a solution?

[krikk]

shortly after last dev build i change a few things in the ina219 plugin, can you try to compile the latest git version and test again with that version...

[robatbentley]

Sorry but I don't know how to compile the git source code. I either need someone to describe how to do this (I have Visual Studio installed) or build an executable for me.

Update 1: Okay, just found the tutorial on installing Atom (et al) and will install the build environment. Let you know how I get on.
Update 2: Blimey, that was an education but managed to build and flash the updates. I can now define the IDX and Domoticz can now see the data. Problem is that the data was originally good but then all went 4.229V and 4.229A. I'll have another look tomorrow morning as to what's up, but it's looking very promising. Very nice tutorial on how to install Atom and PIO, especially for someone that's new to this new tool set. Thanks for that...

[robatbentley]

Had a few wiring problems to power-up the 0x45 INA device, but sorted now. i.e. I can see all 4 devices in the I2C Scan. ...and links to Domoticz reflect this so at least that bit's working.
However, all 4 devices are reading spurious values which appear to be in the 4.0 to 4.5 range for volts as well as amps even when no current is flowing. I'll have to investigate further and get back to this forum.
If anyone else has this working for 4 x INA219 devices then I'd really like to know.

Had more of a play with the electrical side, such as disconnecting all but the 0x40 device, but still the same problem of volts and amps reading the same values. I eventually reverted the same ESP8266 unit back to the 120 build and the same 0x40 device (used with the Dev_10 build) started providing sensible values. All this confirms is that my INA219 0x40 device is working okay, so I have to suspect that there's a problem with the dev_10 build. See attached screen shots of the dev_10 and 120 builds.

[robatbentley]

With a home built dev_10, even the 2nd and 3rd elements of a value (such as volts) seem to be all over the place. i.e. In the 2nd element, I multipled the %value% by 10, and in the 3rd by 100. ...but the values don't make any sense and they appear to be purely random. There's a serious problem here and I'm completely stuck in attempting to use the INA219 device in the DEV builds. I really wanted to use more than one INA device, but even one of them on its own is unuseable. Sorry guys, but it's a real shame that this problem persists. Guess I'll have to wait for a while until someone comes up with a fix. ...assuming anyones actually reading this.

[grovkillen]

Sorry guys, but it's a real shame that this problem persists. Guess I'll have to wait for a while until someone comes up with a fix. ...assuming anyones actually reading this.

No need for that. We do read.

Regarding the problem I have a friend that uses the dev10 together with 1 INA219 to monitor a lawnmower robot and it works just great. If you have the possibility to test another esp board and other INA219 units to test if the problem IS the ESP Easy firmware or hardware.

EDIT: I have been told that my friend compiled a "dev11" on his own. The problem must be in the dev10 it seems, the source file for INA219 was updated just the other day... you might have not catched that update I recon?

[robatbentley]

I'll re-download and clear everything out and start afresh just in case. I have a feeling that I did catch the file update as the selection of IDX returned, but it's worth another go. ...and report back.
I don't mind putting in the time to test the dev builds but it's incredibly frustrating when there's no immediate feedback. However, point taken.

EDIT: I have been told that my friend compiled a "dev11" on his own. The problem must be in the dev10 it seems, ...

Is this based upon the dev10 source code from here https://github.com/letscontrolit/ESPEas ... .0.0-dev10 (which doesn't yet have any downloadable binaries built from it) or have I missed a dev11 branch somwehere?

[grovkillen]

Is this based upon the dev10 source code from here https://github.com/letscontrolit/ESPEas ... .0.0-dev10 (which doesn't yet have any downloadable binaries built from it) or have I missed a dev11 branch somwehere?

Sorry for confusing you. It is a compilation of source codes as of 2 days ago. It is not a dev11 since it has not been released. I shouldn't have called it "dev11", it's more like an nightly

[grovkillen]

With a home built dev_10, even the 2nd and 3rd elements of a value (such as volts) seem to be all over the place. i.e. In the 2nd element, I multipled the %value% by 10, and in the 3rd by 100. ...but the values don't make any sense and they appear to be purely random. There's a serious problem here and I'm completely stuck in attempting to use the INA219 device in the DEV builds. I really wanted to use more than one INA device, but even one of them on its own is unuseable. Sorry guys, but it's a real shame that this problem persists. Guess I'll have to wait for a while until someone comes up with a fix. ...assuming anyones actually reading this.

Okay, together with my friend we have now come to the conclusion that you have misunderstood how the new plugin design work (I know, it's not really clear). You can see that the first two values in your setup multiple the third value. (V*A=W).

Each device has all three values V, A, W (in that order).

See my friends setup:


So when you find them all over the place they are in fact correct but you mistakenly interpret the A and W as volt on the first device etc.

[robatbentley]

Aaaah! Rebuilding from scratch and'll get back once I've sorted which zip to download and rebuild. Thanks

Update1: I've rebuilt and flashed what I think is the correct source code. I can see the same setup as your friend and configured mine to look the same. ...and the figures look sensible now. ...which is great.
However, if I now want to link to IDX values in Domoticz, then how do I do this? as there are no multiple IDX elements (one for volts, amps and power) to allow its configuration?
You're right, it wasn't clear as to how this change to the config structure but guess this is what development is all about.

[grovkillen]

I don't use Domoticz so I can't help you with that one.

[Pietertje]

As far as i know there is no option in Domoticz for all three values in one sensor type, so i think that since this "3 values in 1" update for the INA219 it's not usable anymore with Domoticz, or maybe only for the first value that will be sent wich will be "volt" i think.

[grovkillen]

But you can do it with MQTT I would expect?

[Pietertje]

Not sure about that but i think it's the same problem because you only have one IDX for all three values.

[grovkillen]

Okay, but how does Domoticz get the IDX from the MQTT message?

Just curious, I don't use Domoticz myself.

[Pietertje]

Example:
2017-06-09 18:45:11.825 MQTT: Topic: domoticz/in, Message: {"idx":1,"nvalue":0,"svalue":"50"}

[grovkillen]

Example:
2017-06-09 18:45:11.825 MQTT: Topic: domoticz/in, Message: {"idx":1,"nvalue":0,"svalue":"50"}

So then you could just have a rule that published some other idx value? That would also work.

[Pietertje]

Example:
2017-06-09 18:45:11.825 MQTT: Topic: domoticz/in, Message: {"idx":1,"nvalue":0,"svalue":"50"}

So then you could just have a rule that published some other idx value? That would also work.

I don't really use MQTT/rules yet so don't know if thats possible.

[grovkillen]

It's not a solution, but a workable workaround. Syntax would be something like this:

MQTT

Code: Select all

on INA219#Amps do
	Publish domoticz/in,{"idx":123456,"nvalue":0,"svalue":"[INA219#Amps]"}
endon

on INA219#Watts do
	Publish domoticz/in,{"idx":654321,"nvalue":0,"svalue":"[INA219#Watts]"}
endon

HTTP

Code: Select all

on INA219#Amps do
	SendToHTTP http://192.168.1.2:8080/json.htm?type=command&param=udevice&idx=123456&nvalue=0&svalue=[INA219#Amps]
endon

on INA219#Watts do
	SendToHTTP http://192.168.1.2:8080/json.htm?type=command&param=udevice&idx=654321&nvalue=0&svalue=[INA219#Watts]
endon

(Given that your Domoticz server is on "192.168.1.2:8080")

This lets you have separate IDXs... (in the examples, 654321 and 123456)

[grovkillen]

I also posted this as a Rules Tuturial: https://www.letscontrolit.com/wiki/inde ... th_own_IDX

Not a fix, more like a workaround and good to know if you want to make your own custom publishing to Domoticz.

[robatbentley]

Okay, just found something new in the INA219 device setup in my latest home-built version of the flash bin file (5pm on 12th June 2017). It's the drop-down list of Measurement Types, which used to be only Voltage, Current and Power. ...but now there's an additional Voltage/Current/Power option. I've now selected this, hoping that it'd fix my problem that I couldn't see any way of linking each of these INA devices (except for one of them, in my case Voltage) through to the Domoticz IDX values. Don't think this has fixed my problem but it's another step forward.

[grovkillen]

Okay, just found something new in the INA219 device setup. It's the drop-down list of Measurement Types, which used to be only Volts, Current and Power. ...but now there's an additional Volts/Current/Power option. I've now selected this, hoping that it'd fix my problem tghat I couldn't see any way of linking each of these devices through to the Domoticz IDX values. Don't think this has fixed my problem but it's another step forward.

I hope it fixes the problem, if not you can always use rules (not a general, or official, solution but it is at least a workaround).

https://www.letscontrolit.com/wiki/inde ... th_own_IDX

[robatbentley]

I've tried creating a new Domoticz device and assoicated IDX reference, and configured one of my 4 INA ESPEasy devices but doesn't update the single IDX with anything but the single measurement type, in my case it's voltage. So, the selected value is getting through to Domoticz but can't (without investigating the rule options) yet display volts, current and power in Domotics. I guess this updated INA device needs to have similar properties as per the old (build_120) BME280 Temp/Humidity/Pressure device so that more than measurement type (Humidy and Temp) get displayed in the same IDX device in Domoticz.

However, having just seen the BME280 device in this latest build, I'll need to check that this can be configured to have all it's 3 measurement types be displayed in Domotics. All great fun...
Thanks for the rules reference...

[robatbentley]

Not had time to investigate the BME280 as just blown all my 4 INA219s while moving the circuit spaghetti. Hmm!
Finally replaced and improved the test-bed layout and now back to 4xINA219s and an LCD4x20. The problem is that using the latest home-grown build from yesterday, I can no longer create an LCD device. Please see the screen-shot which is what I see when attempting to edit the existing LCD device. The screen-shot is of an existing LCD device used prior to the new flash file installation. Creating a new LCD device has the same problem. The LCD (and all 4 INAs) devices do appear in the I2C search.
Any suggestions as to what's going on here?

[grovkillen]

Not had time to investigate the BME280 as just blown all my 4 INA219s while moving the circuit spaghetti. Hmm!
Finally replaced and improved the test-bed layout and now back to 4xINA219s and an LCD4x20. The problem is that using the latest home-grown build from yesterday, I can no longer create an LCD device. Please see the screen-shot which is what I see when attempting to edit the existing LCD device. The screen-shot is of an existing LCD device used prior to the new flash file installation. Creating a new LCD device has the same problem. The LCD (and all 4 INAs) devices do appear in the I2C search.
Any suggestions as to what's going on here?

I think it's the bug discussed here that is causing this to happen: https://github.com/letscontrolit/ESPEasy/issues/352

[robatbentley]

Just implemented the rules for the INA devices and it works really nicely. Thanks for that. The pressure's off from my side now that I have that great work-around. It'd be nice to have the LCD device working again but at least I can see my data in Domoticz.
Cheers...

[robatbentley]

Thanks to the guys that fixed the LCD problem for my INA219s. I've just rebuilt the ESP Easy Mega and, despite the config being quite slow to respond (don't know if it's my end or not), but I now have a working 4x20 LCD working.

I'm still using the rules to display the details in Domoticz so this is last remaining issue from my side. No hurry as the rules offer a good work-around.

[krikk]

the issue with the slow config pages it most likely a ram issue, have a look at your freeram with the sysinfo plugin, if it below 20 kb its a problem, you improve this by removing unwanted plugins, if you can compile yourself...

[robatbentley]

Had a look at the system info page and I think it's the "Free Mem: 19952 (26408)" bit I need to look at. ...which, in this case, appears to be just under 20k.
How do I go about removing unwanted modules?

Unit: 17
Uptime: 0 days 1 hours 28 minutes
Load: 34% (LC=8615)
Free Mem: 19952 (26408)
Wifi RSSI: -49 dB
Wifi Type: 802.11N
IP: ***.***.*.***
GW: ***.***.*.***
Build: 20000 - Mega
GIT version:
Plugin sets: [Normal] [Testing] [Development]
Core Version: 2_3_0
Flash Size: 4096 kB
Flash Writes (daily/boot): 0 / 0
Sketch Size/Free: 594 kB / 2476 kB
Devices: 62
Boot cause: Cold boot
Warm boot count: 0
STA MAC: 5c:cf:7f:3b:b0:09
AP MAC: 5e:cf:7f:3b:b0:09
ESP Chip ID: 3911689
Flash Chip ID: 1458376

[krikk]

just delete the files of the plugins you dont need before you compile...

[robatbentley]

Sorry for my ignorance here, but do I delete some of the ino files or lib folders or both?

Update: I went ahead and deleted a number of ino files which I hoped were not used in my INA and LCD application. Lucky guess I think, and managed to free-up some more RAM to about 20k. I'll delete a few more to see if I can free-up some more. Deleted a few more but ran really slow so stuck with my first attempt which is quite responsive. Details below...

I've used the LUA optional build facility here (https://nodemcu-build.com/) and think ESPEasy users could benefit from this sort of solution where spare RAM is an issue. Any thoughts on this?

My system info post reduced build is...

Unit: 17
Uptime: 0 days 0 hours 1 minutes
Load: 0% (LC=9152)
Free Mem: 24528 (20872)
Wifi RSSI: -49 dB
Wifi Type: 802.11N
IP: 192.168.1.106
GW: 192.168.1.254
Build: 20000 - Mega
GIT version:
Plugin sets: [Normal]
Core Version: 2_3_0
Flash Size: 4096 kB
Flash Writes (daily/boot): 0 / 0
Sketch Size/Free: 457 kB / 2612 kB
Devices: 20
Boot cause: Manual reboot
Warm boot count: 1
STA MAC: 5c:cf:7f:3b:b0:09
AP MAC: 5e:cf:7f:3b:b0:09
ESP Chip ID: 3911689
Flash Chip ID: 1458376