[Eric Tsai]

Jeff,
Sorry, that was my fault. I think my corporate laptop is blocking FTP sites on the browser. I was able to download it at home.

Thanks,
Eric

[Eric Tsai]

LOL. Thanks Jason. I didn’t catch that when I RTFM 🙂

[Eric Tsai]

Hi Lawrence,
Thanks for the feedback on that package.

Yeah, having Node on the Conduit seems like it would provide a lot of opportunities to leverage existing integration tools, but because of the hardware is lagging, it’s preventing us from really taking advantage of them.

@Jeff What’s on the road map for the Conduit hardware? Will we get a more updated version of Node?

[Eric Tsai]

Hey Jeff,
You’re right. The correct node red package is node-red-contrib-bacnet. This doesn’t seem to be available in the npm directory right now. I’m not sure how well this works in node-red, and it seems the bacstack package is better tested. So I’ll just go the route of using a node.js script rather than node-red for now.

Thanks,
Eric

• This reply was modified 6 years, 10 months ago by Eric Tsai.

[Eric Tsai]

Hi Jeff,
For the node-red node-bacnet installation, the dependencies are gextend and bacstack. Both dependencies seem to be packaged inside the node-bacnet folder.

I don’t see any errors relating to bacnet in the </var/log/app/node-red.log> file.

I’ve installed OPC-UA node and that shows up fine in Node-Red. It’s available on the sidebar. But not node-bacnet.

[Eric Tsai]

Thanks for confirming.

I tried declaring the wake pin from DigitalIn to DigitalOut prior to executing the RTC sleep. But that did not prevent the wake pin from waking the mDot during RTC sleep.

DigitalOut pin_wake(PA_0);
dot->sleep(sleep_time, mDot::RTC_ALARM);

[Eric Tsai]

Mike,
I’m not setting any wake pins, so there’s nothing to delete. I think it’s being automactially set by the sleep call’s wake mode. In this application, I need to unset the wake pin dynamically.

If I go by this documentation here:

#else
    if (deepsleep) {
        // for mDot, XBEE_DIO7 pin is the only pin that can wake the processor from deepsleep
        // it is automatically configured when INTERRUPT or RTC_ALARM_OR_INTERRUPT is the wakeup source and deepsleep is true in the mDot::sleep call
    } else {
        // configure XBEE_DIO7 pin as the pin that will wake the mDot from low power modes
        //      other pins can be confgured instead: XBEE_DIO2-6, XBEE_DI8, XBEE_DIN
        dot->setWakePin(XBEE_DIO7);    
    }

So whether the Wake Pin is configured as InterruptIn is set by the dot->sleep() call. Could the problem be that the moment you do a <mDot::INTERRUPT>, it sets the wake up pin. It never gets “unset” when I subsequently perform a sleep call that uses <mDot::RTC_ALARM> type wake mode. So the first time a program executes a <mDot::INTERRUPT>, the wake-up pin is set as interrupt forever.

There is a setWakePin() function, but there is no unsetWakePin() function.

[Eric Tsai]

Thanks Lawrence. I was able to install the OPC UA node via npm, but have not tested it against an OPC UA server.

In regards to other industrial protocols, deviceWise publishes a driver list, and they advertise compatibility with the Conduit. Does this driver list apply to mLinux Conduit or is it only for their deviceWise gateway? If the list applies to the Conduit, it seems like an easy way to gain lots of protocols.

https://help.devicewise.com/display/M2MOpen/Device+driver+list

A side question – how do you stop node-red when you’re logged in via ssh, short of killing the process? Is there something like systemd on the AEP conduit? It took many minutes to install the OPC UA node. Wonder if stopping node-red would’ve made a big difference.

[Eric Tsai]

If you’re using the readUserBackupRegister() and writeUserBackupRegister(), those are battery backed registers I believe. They’re cleared when power is removed, but are maintained across sleep.

If you want to write to flash, that’s the saveUserFile() and readUserFile() calls.

[Eric Tsai]

Oh, thanks for the links Jason. That makes a lot more sense than what I was trying to do.

[Author]

Posts