Thijsmans

Most recent activity

• Idea: Espruino PLC

  @Thijsmans started

  • 14 comments
  • 4,167 views

  @Jean-Philippe_Rey replied
• Idea: Espruino PLC

  in General • 4 years, 11 months

  

  Thanks for all thoughts! I have done some thinking about hardware and code. About the hardware:

  • the Railduino and Controllino setup makes me somewhat uncomfortable. The devices are directly connected to 230 Volts. Through relays, but still... I prefer using seperate DIN-rail mounted relays like Wago, Finder, Siemens... Is this why your channels are 3-18v as well, @Gordon ?

  • These use 12V/24V for inputs (pretty standard, PLC-wise), which a GPIO does not supply. I'll go for Darlington-transistors switching a 12V-line.

  • No matter the board, the number of GPIO's is always a limitation for a PLC. I'll use shift registers for outputs (to drive the Darlington-transistors).

  • I've been looking into i2c-port expanders, but in my experience, these work too slow for high speed inputs like rotary encoders.

  • For inputs I'll use opto-couplers, to prevent blowing up the microcontroller with 12V :)

  • I'm planning on doing 0-10V outputs for dimmable LED-drivers, I guess using an op-amp is the way (not familiar with those yet).

  As for as the actual javascript, I'm using several classes (* = not started yet, waiting for parts):

  • PLC (container);
    
  • PLC_Display_128x64 (oled);
    
  • PLC_Input_Digital*;
    
  • PLC_Output_Digital*;
    
  • PLC_Output_Analog*;
    
  • PLC_Bridge (which creates an input and output, and simply mirrors output on input).
    
    

  The 128x64 oled was a tad too small, a 320x240 LCD is in the mail. By using a seperate class with standard functions (mainly .bootscreen() and .update() ), changing the screen should be fairly easy. Hell, you could connect different screens at the same time, if you want to.

  About the modular setup, mentioned before... Let's see how a single unit works out first ;)

• Idea: Espruino PLC

  in General • 4 years, 11 months

  

  @Robin

  but I'll need to be educated on why the current breakout boards are
  not already the heart of a PLC.

  They could most certainly be the heart of a PLC. I guess the problem is that I've got an idea, but not a detailed and solid plan. Neither do I have extensive knowledge about electronics ;-) Especially the modular setup looks complicated... Found this thread about serial communication between Pico's, which could be useful.

  @allObjects thanks for the tip!

• Idea: Espruino PLC

  in General • 4 years, 11 months

  

  Over the last year, I have been thinking about home automation on a higher level then Sonoff (limited lifetime) or 433mhz (limited possibilities) or even wifi (stability issues). Serious automation is usually done with a PLC (Programmable Logic Controller). These come with a price-tag: a Wago PLC with software license easily sets you back € 600. Cheaper options include a Railduino or Controllino, but as the name suggests, these have to be programmed with the Arduino IDE. I guess I just miss the ease of an Espruino PLC :) How cool would it be to program a PLC with something like this:

  var ledDriver = plc.add('analogOut', A1);
  var ledDimmer = plc.add('rotary', { pinA: D1, pinB: D2, pinSw: D3, function () {
      ledDriver.setVoltage( E.clip(this.position, 0, 10) );
  });
  

  The PLC should have an ethernet-port (not wifi) to interface with (for example) Home Assistant, spitting out JSON over a websocket when the plc-class runs an event (like spinning the rotary, in the example above). And the other way around: the plc-class should be accessable over the websocket by feeding it JSON.

  For future expansions, I would opt for a module based system: a main CPU in a plastic case with a small number of inputs and outputs (analog and digital), and optional modules for specific purposes (4 x input, 4 x output, 0-10v output...). The modules would connect to eachother with a USB-like connector system.

  Gordon, any chance of an Espruino PLC happening? Or even a native ethernet Espruino? I would buy (both!) ;-) Untill that time, it seems that an Espruino Original could do pretty much everything I want it to, when combined with a WIZ550io. Does that still require the special build, even though the CC3000-support was removed from Espruino (and the lack of memory should no longer be an issue)?

  Any thoughts on this would be appreciated!

• Rotary encoder and digital potentiometer

  @Thijsmans started

  • 12 comments
  • 5,886 views

  @user102201 replied
• Setting static IP before connecting?

  @Thijsmans started

  • 11 comments
  • 5,343 views

  @maze1980 replied
• Setting static IP before connecting?

  in ESP8266 • 5 years, 7 months

  

  Benchmarked and... well done MaBe :)

  

  A full report can be found @ my Tweakblog, which is dutch but translate pretty accurate using Google.

• Setting static IP before connecting?

  in ESP8266 • 5 years, 8 months

  

  Would love to test, but I can't compile it myself because of a lack of skills ;-)

• Setting static IP before connecting?

  in ESP8266 • 5 years, 8 months

  

  @allObjects Thanks for the intel on possible future enhancements ;) I doubt though if setting a static IP on the AP-side will speed up things. It doesn't change the DHCP-negotiation as such, as far as I know, but just returns the same IP all of the time.

  Thanks @MaBe, I'll look into it! Unfortunately, my AP automatically jumps channels, depending on other network signals. So using a particular channel won't work. The BSSID sounds promising though (or would this only help in a situation with multiple AP's sharing one SSID?).

• Setting static IP before connecting?

  in ESP8266 • 5 years, 8 months

  

  So I found this threat where wifi.setIP() was implemented to set a static IP for an ESP8266. These docs mention "You must be connected to an access point to be able to call this successfully". I thought I misinterpreted it, because: why setting a static IP once connected? Turns out the documentation is right: calling wifi.setIP() before connecting to wifi, does nothing. Calling it once connected actually changes the IP-address.

  I want to get rid of DHCP in the first place. I'm building a battery-fed deep sleep project. DHCP is terribly slow and takes around 4 seconds (which is 40% of the total time needed for measuring and transmitting the results).

  Any thoughts on this?