2021-01-10, 09:03 PM
(2021-01-10, 10:08 AM)tkurki Wrote: 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