PINE64

Full Version: Possible Remote Relay Control Application
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Looking for feedback on a concept application. Concerns are that I am a noob when it comes to most of this, but do have a background in automation, cnc, and electronics. Security is a concern considering the DNS attack via IoT devices.  

Application:
Remote control of relays via I2C.

Current Usage
The application is hardwired between switches and relays, results in being labor and material intensive and not installation friendly. Typically controls 8 relays with no feedback from relay output to indicate a working output or blown fuse condition.

Existing switches are mechanical type. Since these switches have LEDs to indicate status there can be as many as 9 wires to each switch. There would be 2 inputs and 2 outputs at 12 volt levels from each switch. 

Existing relays have 12VDC coils. 

Going Wireless Between Switches and Relays With Feedback:
Concept A
I have located an I2C board that will drive the relays. The I2C digital output board is small enough to fit in the existing relay enclosure. There is also room for the PADI and an I2C digital input board to monitor relay output status. 

For the switches I have located I2C input and output boards that would interface with the Pine64. With 8 switches that would be a total of 16 inputs and 16 outputs. 
The 4 required boards along with the Pine64 can mount near the switches with very short connections. Still labor intensive and not installer friendly without packaging considerations. 

Concept B
Use the same relay system as Concept A. In place of existing switches use NKK Smart Switch pushbuttons with an OLED 96RGB x64 display. The NKK Switches interface to the PINE64 via SPI. This would require me to create an simple interface board to MUX the switches. I would then be able to display various statuses in graphic form on each switch.  Also I could add some analog data and display it on the switches if needed. 

Questions:
Are either concepts doable with the PADI? Can the PINE64 connect to more than one PADI at the same time? I know each PADI would have it's own IP address. How secure can I make this? This will be used in a non critical application but am concerned about outside tampering. Any faults in my concepts that I maybe not thinking of? I am open to any suggestions and criticism. 

NO this is not a commercial product. I do plan to offer it up as Open Source so that others can use it. Sorry for being long winded and detail intensive but wanted to lay out my thoughts on a non-typical use for the PINE64 and PADI. 

Sample of the switches:
[Image: NKK-oled-smartswitch.gif]
(10-25-2016, 10:33 AM)Traveler Wrote: [ -> ]Looking for feedback on a concept application. Concerns are that I am a noob when it comes to most of this, but do have a background in automation, cnc, and electronics. Security is a concern considering the DNS attack via IoT devices.  

Application:
Remote control of relays via I2C.

Current Usage
The application is hardwired between switches and relays, results in being labor and material intensive and not installation friendly. Typically controls 8 relays with no feedback from relay output to indicate a working output or blown fuse condition.

Existing switches are mechanical type. Since these switches have LEDs to indicate status there can be as many as 9 wires to each switch. There would be 2 inputs and 2 outputs at 12 volt levels from each switch. 

Existing relays have 12VDC coils. 

Going Wireless Between Switches and Relays With Feedback:
Concept A
I have located an I2C board that will drive the relays. The I2C digital output board is small enough to fit in the existing relay enclosure. There is also room for the PADI and an I2C digital input board to monitor relay output status. 

For the switches I have located I2C input and output boards that would interface with the Pine64. With 8 switches that would be a total of 16 inputs and 16 outputs. 
The 4 required boards along with the Pine64 can mount near the switches with very short connections. Still labor intensive and not installer friendly without packaging considerations. 

Concept B
Use the same relay system as Concept A. In place of existing switches use NKK Smart Switch pushbuttons with an OLED 96RGB x64 display. The NKK Switches interface to the PINE64 via SPI. This would require me to create an simple interface board to MUX the switches. I would then be able to display various statuses in graphic form on each switch.  Also I could add some analog data and display it on the switches if needed. 

Questions:
Are either concepts doable with the PADI? Can the PINE64 connect to more than one PADI at the same time? I know each PADI would have it's own IP address. How secure can I make this? This will be used in a non critical application but am concerned about outside tampering. Any faults in my concepts that I maybe not thinking of? I am open to any suggestions and criticism. 

NO this is not a commercial product. I do plan to offer it up as Open Source so that others can use it. Sorry for being long winded and detail intensive but wanted to lay out my thoughts on a non-typical use for the PINE64 and PADI. 

Sample of the switches:
[Image: NKK-oled-smartswitch.gif]
You can try the concept A first, I thinks PADI should able to handle. One Pine64 should able to handle multiple PADI connection.
Concerning security: for WIFI always use encrypted connections, so WPA.
For your client/server application to do the interaction: a TLS protected connection is preferred (so HTTPS if you want to use HTTP, or plain TLS to protect plain TCP/IP communication).
Ideally you'd setup this connection using both server and client certificates (normally with HTTPS for example only server certificates are used since only the server+connection needs to be verified/secured). Client certificates are a much stronger variant to username/password login, which should keep out any unwanted visitors (given that you do not allow any other connections and use a proper TLS implementation). The main weakness of passwords is that they are usually to easy, and the recent hack was even due to IoT devices for which a default password was used (and never updated).
(10-28-2016, 07:38 AM)pimvullers Wrote: [ -> ]Concerning security: for WIFI always use encrypted connections, so WPA.
For your client/server application to do the interaction: a TLS protected connection is preferred (so HTTPS if you want to use HTTP, or plain TLS to protect plain TCP/IP communication).
Ideally you'd setup this connection using both server and client certificates (normally with HTTPS for example only server certificates are used since only the server+connection needs to be verified/secured). Client certificates are a much stronger variant to username/password login, which should keep out any unwanted visitors (given that you do not allow any other connections and use a proper TLS implementation). The main weakness of passwords is that they are usually to easy, and the recent hack was even due to IoT devices for which a default password was used (and never updated).

Thank you,

You have given me some insight into what I will have to do. Unfortunately we all suffer when people are naive enough to believe their internet accessible cameras would be no interest to anyone. They may not be for the data they display but for a hacking access they were the perfect hole in the file.

My concern is that someone passing by could gain access pretending to be a server. As this applicationis mobile, it provides an opportunity for the connection to be seen. At the present time no physical or equipment harm could be done other than a dead battery. Maybe if it proves to be secure enough it could grow into being keyless access. Current automotive keyless products are so weak in security that anyone standing close enough between the master and slave can clone the master with the right equipment. Software Defined Radios have enabled sniffing and decoding the traffic between two devices. Encrypted data on server and client is necessary to prevent sniffing. Passwords should be longer than the number of fingers and toes you have, no common words or names, contain symbols, numbers, and be upper and lower case.