mLink 1ch (HCMODU00182), 2ch (HCMODU0183), And 4ch (HCMODU0184) I2C / Parallel Relay Modules

[lewsut]

Thanks Andrew,

Unfortunately this pushes me into using the mLink library that currently doesn't support alternative i2C busses? (I'm using C/C++ not python currently)

I guess I'll either have to edit the lib or scrape out the bits I require to make this work.

Yes in principal what you have suggested would solve my problem, however I had not read too much into the library as I can't currently easily make use of it.

However you do state this time is stored via NVM so perhaps I could programme it separately via the default wire on another MCU then hit the relays via Wire.write. I'll have a play around and report back

[andrew]

Unfortunately this pushes me into using the mLink library that currently doesn't support alternative i2C busses? (I'm using C/C++ not python currently)

I guess I'll either have to edit the lib or scrape out the bits I require to make this work.

However you do state this time is stored via NVM so perhaps I could programme it separately via the default wire on another MCU then hit the relays via Wire.write.

Quoted from a different thread...

I'm mostly a C/C++ guy I'm unlikely to use this board with Rpi and thus Python so I'll whip something up to utilise wire1.

Sorry, I forgot about our previous conversation and so was assuming you were using an Arduino. So am I correct in assuming you're using the module with a Raspberry Pi but your current plan is to use C++, not python (so that you can use it with an alternate I2C port) ?

[lewsut]

Hi Andrew,

Sorry I didn't make it clear there is no PI involved in this project, purely "Arduino" (ESP32).

I thought you said in the previous post that there was no easy way of using the library with a different bus in C++?

I think I have this issue sorted, I'll add timers to all relays via a different Arduino, then use my code that currently works to switch the relays.

Update: Tested and almost working, it seems I can't override the timer with Wire.write, rather annoyingly. So i am sending a command to open the relay and it just waits for the timer to finish, that's not ideal.

[andrew]

Sorry I didn't make it clear there is no PI involved in this project, purely "Arduino" (ESP32).

I thought you said in the previous post that there was no easy way of using the library with a different bus in C?

My apologies also, for some reason I was under the impression that you were using a Raspberry Pi. But that said, the issue is the same for the Arduino mLink library. For I2C communication It makes use of the standard Arduino wire library. This library (AFIK) does not have any option to specify an alternate I2C port.

Update: Tested and almost working, it seems I can't override the timer with Wire.write, rather annoyingly. So i am sending a command to open the relay and it just waits for the timer to finish, that's not ideal.

I would not recommend making repeated writes to the timer registers anyway. Although it is quite high, the NVM that is used to store the timer value only has a limited number of writes.

Each time you retrigger the relay it resets the timer even if it is currently running; so, would setting the timer to say 5 seconds then just repeatedly re-triggering the relay within that 5 seconds period work for your application? I.e. a dead man's switch?

[lewsut]

I would not recommend making repeated writes to the timer registers anyway. Although it is quite high, the NVM that is used to store the timer value only has a limited number of writes.

I am only setting the timer once using another MCU that I can use the standard bus, it is not being repeatedly written. This was just for testing of how the timer worked.

Each time you retrigger the relay it resets the timer even if it is currently running; so, would setting the timer to say 5 seconds then just repeatedly re-triggering the relay within that 5 seconds period work for your application? I.e. a dead man's switch?

Not in this instance, consider my application. I have a valve that is automatically, or manually overridden. I would like to be able to turn on and off these valves as I please (I can do this without the library obviously). I pulse the relay board with a byte every second, it's nice to see the relay board flash and I can implement any missed state changes, and when used, to refresh the countdown timer.

Now the issue comes when or if there is a loss of comms, that's where the library's timer is seemingly perfect... unless you wish to turn it off within that timing to off's time. I have a GUI where I can (could) open and close the valves as fast as I would like, however this ability is lost with the timer. I believe this timer should have an interrupt to cancel if a new command is received (I believe) .

So my choices are, a fast and responsive GUI to valve control, with no loss of comms mitigation (this could end up with a stuck open valve and water everywhere). Or A slow GUI where I have to wait a second for my valves to close and no loss of comms fail safe... this is also annoying as it looks bad and i can easily over fill a container in just 1 second or less.

There are many boring and arduous ways to solve this, however it would be nice if the relay time could be interrupted and superseded with a command, especially an important one like deenergise.

[andrew]

Ok, I think I understand your situation. Simply you want the relays to automatically de-energise after a set period of time without any software interaction (in case the software crashes), but you also want to be able to override an energised relay at any point. Which I agree, it would be a nice feature to override an energised relay in timer mode.

I don’t think setting the timer to 0 would be a good solution though as it can encourage repeated writes to the timer register(s) and potentially wear out the NVM. Not an issue for you of course, but potentially a problem with other customers.

Another option could simply be a case of changing the firmware so that setting the relay low overrides the timer. The potential issue there is that it will change the behaviour of the relay and we already have a lot of these in the wild so I’ll need to have a think if that would be a significant enough change to cause a problem with repeat customers.

A firmware feature update of course doesn't help your current problem but I can’t think of any workaround beyond what you have already suggested.

[lewsut]

Thanks for taking the time to reply, I think that about covers it. I'm testing various i2c relay sets and this is about the most comprehensive and ultimately editable one so far.

I'm from an industrial PLC control system background so I'm probably far to cautious about loss of control and Comms... and not being able to cancel a timer on an output is a big no no.

I'll keep an eye on your products the are useful!