I2C sensor driver hacking

[Collco]

Thanks I’m new to this, but I’m having fun! I have some dev experience in low code environments, but I don’t know python - however I approach everything in life from a starting point of “ how hard can it be? “ (The answer usually is slightly harder than you think!)

Anyhoo, I’m looking for some advice. 

I’ve got a wave share power monitor hat which has 4nr I2C chips on it (Ina219 chips) these are not supported by the IC2 app built into OP. (Yes I could trade them for INA260s which are supported, but but they are an order or magnitude more expensive and where’s the fun in that?) 
So I’ve found a node for Node red (https://flows.nodered.org/node/node-red-...219-sensor) which will interface with them. Cracking. Means I’ll have to dashboard in node red but that’s ok. The node has. Drop down menu to select the address for Ina219 chip you want to access, the  possible addresses are:
0X40
0X41
0x44
0X45

When use the first two addresses the plug-in works flawlessly, when I use 0x44 or 0x45 it returns no data. 

I’ve done some digging, both with the OP I2C app and the documentation for the HAT and both imply that the correct addressing should be:
0x40
0x41
0x42
0x43

There is no option in the config of the plug-in to change this.


So I did some digging through the scrips from the plug-in and it turns out it references (ports was the word it used) a 3rd party driver for the INA219 which it installs as a dependant and this has the address references built into the JS code. 

Now, I tried what i now understand to be a hopeless noobie move of just editing the files in both the driver and node to reflect the “correct” addressing which obviously doesn’t work. 

I understand I need to “fork the development” and do something in a dev environment in order to make my edits. (If they’ll even work) 

I’m out of road. It seems like a relatively simple edit which might benefit others if I can publish it (as a new node red node maybe?) afterwards, but I don’t know how to do it. 

Can anyone sense check my logic to this point, and point me to a resource to help me understand how to make and test my edits. 

Thank you please!

[tkurki]

Have you considered reporting the problem as a Github issue to the authors of the modules you are using? They might be able to offer assistance, both in making things work without any code changes and in how to go about fixing the problem. If you report with pointers to where you think the problem is all the better, as it shows to the authors that you've put effort into trying to find the root cause. Often you can get help that way, if the module that you use is not abandoned.

Publishing your version as a new module is a no no in my books, if you do not first try to get the changes "upstream", meaning included in the original module and a new version published. Otherwise there will be two modules, with a slightly different set of bugs and features. If the original module gets a bug fix or a feature your version won't and vice versa.

If the upstream module is not accepting any or your change only then you should publish a new one.

Having said that I can suggest an alternative avenue of attack: skip Node-RED and get first the INA219 communication working. Maybe you are using https://github.com/brettmarl/node-ina219? Just take the example code and make it work for your use case. Then when you have it working by itself you can consider how to integrate it with the rest of the system. I would personally create a Signal K server plugin, but I have a certain bias, as I am one of the primary authors of SK server. Still, it is a very good option. If you use the embedded version of Node-RED you can create still create your dashboard in Node-RED, as SK data is available handily.

PS Use i2cdetect to check the active addresses on the bus

[Collco]

Have you considered reporting the problem as a Github issue to the authors of the modules you are using? They might be able to offer assistance, both in making things work without any code changes and in how to go about fixing the problem. If you report with pointers to where you think the problem is all the better, as it shows to the authors that you've put effort into trying to find the root cause. Often you can get help that way, if the module that you use is not abandoned.

Publishing your version as a new module is a no no in my books, if you do not first try to get the changes "upstream", meaning included in the original module and a new version published. Otherwise there will be two modules, with a slightly different set of bugs and features. If the original module gets a bug fix or a feature your version won't and vice versa.

If the upstream module is not accepting any or your change only then you should publish a new one.

Having said that I can suggest an alternative avenue of attack: skip Node-RED and get first the INA219 communication working. Maybe you are using https://github.com/brettmarl/node-ina219? Just take the example code and make it work for your use case. Then when you have it working by itself you can consider how to integrate it with the rest of the system. I would personally create a Signal K server plugin, but I have a certain bias, as I am one of the primary authors of SK server. Still, it is a very good option. If you use the embedded version of Node-RED you can create still create your dashboard in Node-RED, as SK data is available handily.

PS Use i2cdetect to check the active addresses on the bus

Thanks very much for your suggestions. I agree, it would be great to have it in SignalK (that's where absolutely everything else I'm interfacing with lands) but since I had a starting point for Node Red in the easybotics ina219 plug in that's a far more realistic option for my skill level. 
As a development from that, it would be brilliant to add it to the list of supported I2C sensors in OP which would make setting it up pretty idiot proof, but again that's well beyond me. 

You make good points about being careful with code so as not to make it an orphan, I was hesitant to engage with the developer on GitHub as I really don't know what I'm doing so I wanted to make sure that my plan actually worked! 

I've now done that! Using i2cdectect as you suggested, thank you for that, I've confirmed that the addressing of my device should have been 0X40, 0X41, 0x42 and 0X43 and after some fumbling about in the dark I discovered a config file in node red which pointed to the location of the plugin scrips which were actually being used, and by searching each of the files in the three directories associated and replacing the address details, I've now got it functioning. 

I know this isn't a proper solution, as all I've done is damaged someone else's software so I'll now post it as a suggestions on GitHub and I'll also make a write up of what I've done and post it either in "How i did it" or the node red section. 

Thanks

G