Project Logs

Collapse

• Figuring out requirements

  Jason K • 05/07/2019 at 14:03 • 0 comments

  Voila, I am a mega hardware maker. So what do we have? We can get ESP32 as a chip or a Dev Kit board (DevKit1). What do we need?

  - a box so that we can mount the device either on the DIN rack or on the wall, depending on the specific situation

  - in order not to look for exotic power sources, we want to feed the box from 12V - a very common non-nonsense voltage

  - we need a lot of inputs and outputs to minimize the required number of devices for large-scale automation. According to my approximate calculations it seems to be: 50 buttons, 15-20 groups of sockets, 25 groups of lamps, 10-15 motor mechanisms , 50 sensors (temperature, movement, humidity, opening, lighting, etc.)

  - another nuance: many relays take 5 volts for a control voltage, and esp32 gives 3.3 volts for output. If we do not address that we will have to fool arount with level converters, which is no fun. So we will need to embed the converters inside. And we never know, occasionally we might need 12v signals.

  - the same’s true for the inputs - we need to think over to learn how to accept different voltages within reasonable limits. To test the hypothesis, I looked at typical mass sensors and did not find a single digital one that won’t work with 3.3v. But that is a common case for analog sensors. Therefore, it turns out that at least for analog we need to precisely take care of receiving different voltages.

  - the flow of my thoughts also led me to the idea of powering the low-current sensors from the box itself, so as not to look for additional adapters. And again the supply voltage can be different, it means that we need to support a variety.

  - display! in spite of the fact that the device implies autonomous operation, live updates and web interface, the human-readable output of some critical information on the body wouldn’t hurt - no blinks or Morse code to understand what went wrong

  - last but not least, ESP32 has got only wifi - and although it suits myself, we think about people, so we don’t need to forget about good old and reliable ethernet (as well as the cost price of a future device when implementing these)

  Now at once we will find some kind of a box, more or less satisfying the requirements. Let us understand how much space we have, and form the stated characteristics.

• Why ESP32 is actually reliable?

  Jason K • 05/07/2019 at 14:02 • 1 comment

  So our winner is ESP32, woohoo! According to the set of criteria, it is quite suitable for our undertaking. And, since we stopped at it, a couple of words about reliability, as promised.

  From the moment of my fleeting acquaintance with ESP, initially with ESP8266, and then with ESP32 on channels and forums, I occasionally meet the opinion as follows: "Yes, esp is the same unserious Chinese crap from whoever it is unclear. I took the NodeMCU with lua on board, copied the anonymous script and it's all buggy !!! 111 ". So, of course, I won't say anything because of my wild incompetence in this area. But on the topic of the firmware, the following opinion holds: yes, as a person familiar with the Chinese (and not only) coding school of thought, I can assume that the glitches and bugs in the system are numerous, which conforms with the list of closed and open problems in the manufacturer's repository. But:

  - First, it’s other guys’ flaw as well and often they don’t even bother to open their repository (https://github.com/espressif/esp-idf/issues?utf8=%E2%9C%93&q=is%3Aissue) for prying eyes, so it’s difficult to estimate the scale of disasters.

  - secondly, the majority of absolutely critical lousy bugs were caught at the dawn of chip development in 2016-17 - the current list is much less harmfull.

  - thirdly, I myself saw some cases where dozens of esp32s have been working without failures for months.

  - Fourth, we are developing a device for the home, and not for rocket science. Therefore, the requirements for reliability and resistance to external factors during operation are relatively benign.

  - Last but not least: beginner home-made products builders often do not use the official sdk as a framework for their development, but rather use various add-ons, such as the lua interpreter, arduino-esp32, micropython, there seems to be over 9000 them. These add-ons appear out of an honest desire to make our life easier, especially if you already had experience with Arduino or Python. But let's face it: if we take a less than perfect sdk base and add some less than perfect frameworks and some non-perfect code on top of it, what is our chance of success? That's right - ah-oh!

  Well, the conclusion: I’m taking the official SDK for the firmware, Visual Studio Code for an IDE and go ahead. I’m not going into excessive detail while describing the software part, since it will take me as much time as coding itself and focus more on the development of hardware. Moreover, before we code anything, we must first design the hard stuff, based on the requirements and I will do just that!

  We will continue our pursue of the right amount of detalization due to public demand.

• Choosing the core chip

  Jason K • 05/06/2019 at 13:30 • 0 comments

  Now, it’s time to choose a basis for our development. So, we need:
  1) a decent number of inputs and outputs. With support for i2c (for a number of sensors), ADC (for analog sensors), PWM (just in case for motors). I.e., as simple as possible to support typical home scenarios;
  2) ethernet and/or wifi to communicate to the outside world
  3) low cost. we want to overcome the system)
  4) reliability, worthy of home appliance
  4) some ready-made developments from the community or the manufacturer, so as not to lose time on the invention of the wheel (stop, and what am I doing here at all! Oh, shii ...)
  5) and in general so that the development is not as complex as construction of the Large Hadron Collider.

  Our candidates are: stm32, atmega2560, esp8266, esp32, cc3200, teensy, rtl8710, raspberry pi. That seems to be all. Who wants details on them, google - the Internet is inundated with info.

  I will briefly describe them:
  stm32 - known, reliable, relatively expensive, there are no network interfaces in the basic harness

  atmega8260 is a well-known, seemingly reliable, mother of arduino handicrafts, but constant torment in search of extra kilobytes for the stack can drive a developer into boredom (maybe I’m just awkward). there are no network interfaces in the basic harness

  esp8266 - already known handicraft, has a reputation for being unstable (about the reasons later), super-cheap, friendly to developers, there is wifi out of the box

  esp32 - according to the characteristics compared with the previous one, as T1000 versus T800. But at the same time, it still does not seek to kill someone. Slightly more expensive, more reliable (again about this later), friendly, wifi out of the box

  cc3200 - in contrast to the previous two - from a solid manufacturer, therefore, proven and reliable. full of demos from the manufacturer, but not very popular among mommy’s home-makers, like me. Not cheap, but my local pusher says he knows where to get cheaper if I’m interested. Wifi out of the box.

  teensy - dick knows what that is. I just found it in Google, I have not heard anything before and I don’t see any big advantages.

  rtl8710 - some realtek response to esp's growing popularity. Cheap, more reliable reputation, out of the box wifi, but they forgot about the developers. Not that much Info, the community is scanty, I haven’t met any practical solutions, but there are a couple of chips lying around at home. If I had not found a chestnut, I would have planted them.

  raspberry pi - what the hell is Donald Trump doing here? - the imaginary reader could ask. Well, that happens, yes. There are examples when people just take raspberries and connect sensors and relays directly to it. And I do not even condemn them - we are all sinners, and sometimes it is convenient and practical. But for me, it’s rather an overkill in terms of capacity and there’s no official support for any real-time OS, like freertos on it, but we are serious people and are engaged in home automation, so without realtime anytime soon.

  A shrewd reader could already guess who is the winner in this unequal fight, but the street sun whispers to me to take a break

• Just a little bit of explanation

  Jason K • 05/06/2019 at 13:27 • 0 comments

  Perhaps there are those of you who might want a more detailed answer why this project actually exists. Therefore, this is the case: look, when I decided to bog down in the world of automation, I did not plan to invent any devices. So for the beginning, I decided to study the market, because it is unlikely that I want something unique and perverse - all I need is a decent number of inputs, a decent amount of outputs and that the device itself to be able to communicate with the head unit from point 3 by wifi or via ethernet.
  To my surprise, neither Google nor my acquaintances provided me with a lot of options to choose from: a series of devices from our Chinese friends and a couple of good old domestic companies. According to reviews, some of the devices had crappy firmwares and the network dropped off under certain circumstances, costs were prohibitive for the others (there were also all sorts of cloud services and mobile applications coming with them, so apparently they were just trying to earn their buck). I deliberately do not name the models and companies so as not to ruin them - there may be the case where we just do not know how to use them properly, and my two subscribers will wrongfully ignore them and not invest their fortune into their products.
  In addition, there are completely DIY projects in the form of separate development versions of different controller chips and all sorts of firmware (based on arduino or esp) from their communities, implementing the appropriate functionality. But the crap is that even if we take them, how to use them in real life then? In the sense of where to fix them, how to connect the power, so that is reliable and doesn’t drop off at any sneeze? Therefore we need a suitable box, we need normal outputs, connectors, etc., which means that our own board with fasteners and wiring is not far off, not to mention the fact that there must be a written or pre-configured firmware that takes into account this hardware design.
   
  As a result, having a miserable experience in radio engineering (I bought a soldering iron to reset a password), a little bit more experience in product development, a desire to save on these stupid controllers, as well as a thirst for inventions, I moved on to the development of my own device.

View all 4 project logs