uPyEasy

Message

LisaM · #1 Post by **LisaM** » 23 Sep 2017, 17:16

As you might have heard i'm busy developing the next generation of ESPEasy called uPyEasy (micropython easy) which is based on Python instead of C(++).
It's still in the VERY early stages of investigation/development and so far only a small part of the uPyEasy core is build namely the webserver part (the most important and complex part besides the timer cores).

uPyEasy has the following requirements (Last updated: 11-04-2018 ):
- Written in Python
- Multiple platforms (basically all platforms supported by micropython, basic testing/development done on Linux/PyBoard/NodeMCU/ESP-01)
- Async webserver
- Template based webpages (attached the homepage as example)
- Lan/WLan transparancy
- Support for GPIO, I2C, SPI, UART, I2S, CAN and MODBUS interface protocol
- SSL support (server and client)
- Minimalistic HAL
- Maximum reuse of libraries
- Rules in python (unleashing really powerfull rules!)
- Override in plugins (custom plugins overrule standard plugins)
- Plugin drag 'n drop (limited in smaller soc's due to memory constraints)
- Support of ANY library that is supported in micropython
- Support of viper speed
- Dynamic support of SD card
- Support of psRam
- Use of FileDB to store config and other values
- Bootloader supporting OTA firmware updates (Yaota8266, 247KB), meaning 1MB esp's will have 750KB free at most when using OTA.
- i18n support
- Json rest api
- Basic http authentication

Some screenshot of the work so far:

upyeasy.home.JPG

The 'new' home page, added and replaced some info.

upyeasy-config.JPG

The 'new' config page, the wifi/ip fields are read-only here because on a OS like linux you cannot control the ip address, this has to be done by the OS. For a PI Zero board this is relevant. Non-OS's like PyBoard or ESP8266 will control these fields through micropython.

PLEASE let me know IF you have other requirements for uPyEasy or wish to help by making parts of the program! There is plenty of work to do! This program has a GPL v2 license, since i do not wish that corporations run off with the product without contributing to it or even worse file patent claims against us (which is possible when using the MIT license).

Ps. the number of (SOC) boards supporting micropython is growing FAST: https://github.com/micropython/micropyt ... ds-Summary

grovkillen · #2 Post by **grovkillen** » 23 Sep 2017, 20:07

Wow, you've been busy! Interesting to say the least. Will love to try it once I get the time. Python based rules!!!

My main focus is the plugins that need wiki pages written. But I guess the parallel development isn't a problem since allot of GUI is the same to the end user?

LisaM · #3 Post by **LisaM** » 23 Sep 2017, 21:34

grovkillen wrote: ↑23 Sep 2017, 20:07 Wow, you've been busy! Interesting to say the least. Will love to try it once I get the time. Python based rules!!!

My main focus is the plugins that need wiki pages written. But I guess the parallel development isn't a problem since allot of GUI is the same to the end user?

For the first release the GUI will be as much as possible identical. After that everything is possible since it's template based, it can be changed on a dime...

Some invisible changes are already done, so is the CSS now a separate file. That also applies to the javascript file. The webserver is capable of serving plain files, like the css and js files. It will also have images as they are now easy to add.
For the Sonoff/ESP01 boards a stripped down version might be needed, so far however the image is just 587KB including the frozen modules. uPyEasy can almost double in size before it becomes to big to install on the smallest esp's. More modern ESP8266's have 4MB, more then enough for even the biggest vesion. Using spRam, the amount of available memory can even grow to as much as 16MB (still nothing compared to the $10 512MB Pi Zero W...)
The directory structure currently in use by uPyEasy:

upyeasy dir.JPG

LisaM · #4 Post by **LisaM** » 26 Sep 2017, 01:14

micropython's BtreeDB class improved and put to work in uPyEasy. Module scan is used for dynamic use of controllers, plugins and scripts (rules). All are python classes which MUST start with CONTROLLER_xxx, PLUGIN_xxx SCRIPT_xxx, where the xxx-names must be unique names. Plugins will keep their current structure, albeit in python offcourse.

Shardan · #5 Post by **Shardan** » 26 Sep 2017, 17:22

Just an idea...

Is it possible to create a compile script including the possibility to chose modules?
The small ESP's like Sonoff, ESP-01 etc usually do not need a lot of modules as they are
very limited with GPIO.

Even bigger hardware might benefit from that as unneeded modules take up ressources and
do not improve stability and speed.

I've seen that a while ago with some software - it showed a webpage where some
modules were fixed (core etc), other modules could be chosen as needed.
That was nice.

Just my 2ct...

Shardan

papperone · #6 Post by **papperone** » 26 Sep 2017, 18:01

I think this is something we can abstract from the firmware (ESPEasy or uPyEasy).

As we introducte conditional compiling already as NORMAL/DEV/TEST I think it can be worth to add "MINIMUM" for devices like Sonoff or ESP01 where just bare minimum set of pluings will be included.
I think this can overcome the ageing of 1Mb devices...

I will propose that in GiHub

Shardan · #7 Post by **Shardan** » 26 Sep 2017, 19:45

papperone wrote: ↑26 Sep 2017, 18:01 I think this is something we can abstract from the firmware (ESPEasy or uPyEasy).

As we introducte conditional compiling already as NORMAL/DEV/TEST I think it can be worth to add "MINIMUM" for devices like Sonoff or ESP01 where just bare minimum set of pluings will be included.
I think this can overcome the ageing of 1Mb devices...

I will propose that in GiHub

Well, even if it is the right direction that's not really what i meant.
If you see things like Sonoff - why should i have a module for a BME280/BMP180 for, or I²C at all?
But there is another way round too: I'm using several "mini sensors" just with an ESP-01 and a BME/BMP for example.
Other ESP-01 just drive a display.
That's why i suggested a tailored compiling. As there is a conditional compiling already it should be possible
to implement that by moving the compile mark "Testing, Dev" etc out of the source files into a kind of editable list.

BTW this doesn't have to do anything with aging.
Why should a manufacturer put a 4MBit Flash into a circuit where a 1MBit is fully sufficient?
That's the way a technician thinks - business economists think in another way.
If an 1 MBit flash would be 0,1ct below a 4Mbit, they won't implement a 4MBit.
For you and me it won't be a difference. For an industrial production producing a huge number of devices it is a difference.

papperone · #8 Post by **papperone** » 26 Sep 2017, 22:16

Shardan wrote: ↑26 Sep 2017, 19:45 Well, even if it is the right direction that's not really what i meant.
If you see things like Sonoff - why should i have a module for a BME280/BMP180 for, or I²C at all?
But there is another way round too: I'm using several "mini sensors" just with an ESP-01 and a BME/BMP for example.
Other ESP-01 just drive a display.
That's why i suggested a tailored compiling. As there is a conditional compiling already it should be possible
to implement that by moving the compile mark "Testing, Dev" etc out of the source files into a kind of editable list.

BTW this doesn't have to do anything with aging.
Why should a manufacturer put a 4MBit Flash into a circuit where a 1MBit is fully sufficient?
That's the way a technician thinks - business economists think in another way.
If an 1 MBit flash would be 0,1ct below a 4Mbit, they won't implement a 4MBit.
For you and me it won't be a difference. For an industrial production producing a huge number of devices it is a difference.

Well, when I though about a "MINIMUM" compiling I was thinking to strip down 50/60% of current plugins leaving the most used ones.
Thinkg out loud makes sense to keep environmental sensor but, for example, who will connect and ADS1115, HK16K33 (and many many more!) to a basic Sonoff or ESP01 module?
Really, if we look at the 70+ plugin in the current 2.0.0 GitHub repository, I truly believe half of them are not really "generic" ones that can be easily removed form what I would consider a "MINIMUM" build.
This is just bare theory as I've no clue if deleting half of the plugins will make the BIN small enough to fit on a 1Mb module and still enabling OTA but it's a reasonable guess.
Going back to last argument, ageing, it's not about only costs but I can be quite sure that today producing 4Mbit memory module is more expensive than 16Mbit ones as biggest bulk manufacturers shift very fast to newer technologies dropping the older. Same happens with PC, cellphone, TVs, or anything which is "commercial" unfortunately, that's why today we have cellphones with 32Gb or more, 4k resolution 5" screeen or other really stupid piece of hardware....

LisaM · #9 Post by **LisaM** » 28 Sep 2017, 01:23

It's all a moot point now, since i made all controllers, plugin's and script dynamically loading. All .py files in the controller directory are loaded dynamically, regardless of name. The file is then verified (QC!) if all mandatory functions are present and if so, the controller is added to the controller table and the choice becomes visible in the controller add web page.
Want a smaller uPyEasy? Just delete controllers, plugins and scripts you don't need from the standard set, run make to create a new frozen image and done... It's now completely customisable, the only thing you can't delete are the core files but so far the total is only 476KB.
Attached a sample version of the domoticz controller file, the mqtt send part is largely done (please notice the cleanness and simplicity of the code

). A (dummy) plugin is next.

LisaM · #10 Post by **LisaM** » 06 Oct 2017, 08:47

Completed controllers and hardware page:

upyeasy controller.JPG

Controllers for protocols which are not present at bootup are auto removed during init, since protocols are dynamically loaded and could be missing after deleting the protocol file. Small changes to the layout are applied, due to efficiency (like adding delete button).

upyeasy hardware.JPG

No UI changes here

grovkillen · #11 Post by **grovkillen** » 06 Oct 2017, 09:07

Nice! I like the controller UI.

AndrewJ · #12 Post by **AndrewJ** » 06 Oct 2017, 12:11

This is a fascinating topic, thanks for posting. Looking forward to being able to try it out.

budman1758 · #13 Post by **budman1758** » 07 Oct 2017, 15:47

Just ordered me a couple ESP32's. Can't wait to give it a go.

frank · #14 Post by **frank** » 08 Oct 2017, 19:46

is there a beta version lisa. i want to test the py version

LisaM · #15 Post by **LisaM** » 09 Oct 2017, 01:19

frank wrote: ↑08 Oct 2017, 19:46 is there a beta version lisa. i want to test the py version

Sorry, not yet. Not even an alpha version, i'm releasing an alpha first when there's a fashionable alpha version available. 70% UI dev completed, 40% overall. So it might take a while before getting there. Development is done on ubuntu, due to dev cycle speed, but ubuntu doesn't have io ports. First real release will be pyboard (which has over 20 available io ports, fixed ethernet and a lot of other goodies) and also the esp32. ESP8266 release has low prio, since ESPEasy is already available there.

LisaM · #16 Post by **LisaM** » 09 Oct 2017, 22:10

An example of a uPyEasy plugin, some minor changes in the UI are done:

upyeasy device.JPG

Since uPyEasy has to run on multiple platforms, the pin numbering has changed to a generic D0-D16 (and more later for big boards like pyboard). In between brackets right next to it is the local numbering, in this case the ESP8266. For example ESP32 has a D0-GPIO, D1-GPIO-1 relation.
Changed is also the controller section to a more friendly pulldown menu.
The plugin is changed from 'switch' to a more generic GPIO Control type plugin, both for input and output.

grovkillen · #17 Post by **grovkillen** » 10 Oct 2017, 05:44

Some of those changes might be all right for the current Mega branch?

LisaM · #18 Post by **LisaM** » 10 Oct 2017, 21:22

grovkillen wrote: ↑10 Oct 2017, 05:44 Some of those changes might be all right for the current Mega branch?

I always find it annoying when i have more then one controller, which controller is using which protocol. Some of my devices have both Domoticz HTTP and Domoticz MQTT, since not all devices work properly using MQTT (like the MH-Z19, who's only working through HTTP). So surfing back and forth, trying to remember that MQTT is controller 1 and HTTP controller 2...

grovkillen · #19 Post by **grovkillen** » 10 Oct 2017, 21:47

That is a everyday hassle!

Martinus · #20 Post by **Martinus** » 11 Oct 2017, 20:06

Have one of these devices waiting for some useful task. Looks like a suitable module to run uPyEasy.

OPI-Zero.png

It currently runs Armbian (Debian Jessie) and python is already included in the image.

LisaM · #21 Post by **LisaM** » 12 Oct 2017, 01:50

The Pi Zero is using a broadcom cpu, so i wrote it off. The orange pi, which i saw at ali for just $10, is using an arm which is better but still no official micropython support. Python v3 might be suitable, since micropython is v3 compatible.
There 's an old thread here: https://forum.micropython.org/viewtopic ... 2&start=20 about regular linux running python and it has some serious problems for real-time apps like upyeasy (if you get an interrupt during an i2c handshake of 25ms or longer, you're toast!).
Armbian of tinycorelinux might be suitable, provided that there are as little interrupt as possible (meaning bare linux), lucky for us i2c is a kernel module in armbian. Dunno for spi, but something simular might be the case.
I already had ordered an orange pi h2, when i get it i'll test if it works (orange pi zero+python+upyeasy)

LisaM · #22 Post by **LisaM** » 13 Oct 2017, 01:35

@uPyEasy, rules are gone. Enter scripts!

upyeasy scripts.JPG

upyeasy script edit.JPG

Full use of micropython, event driven calling of function main.

grovkillen · #23 Post by **grovkillen** » 13 Oct 2017, 05:32

awesome

Shardan · #24 Post by **Shardan** » 13 Oct 2017, 10:56

LisaM wrote: ↑12 Oct 2017, 01:50 The Pi Zero is using a broadcom cpu, so i wrote it off.

As all Raspberries use Broadcom CPU's does this say upyEasy does not run on Raspberry Pi?

In fact Broadcom CPU's use ARM kernels too so i don't understand why a Orange Pi might work but a RasPi does not.

alpat59 · #25 Post by **alpat59** » 13 Oct 2017, 13:40

A really fantastic job, Lisam! Is there some ideas about release date? Also beta version just to test the product will be appreciated. Thank you

LisaM · #26 Post by **LisaM** » 13 Oct 2017, 15:39

Shardan wrote: ↑13 Oct 2017, 10:56 As all Raspberries use Broadcom CPU's does this say upyEasy does not run on Raspberry Pi?

In fact Broadcom CPU's use ARM kernels too so i don't understand why a Orange Pi might work but a RasPi does not.

uPyEasy runs on micropython, which doesn't exists for Raspberry or Orange Pi's (it does for linux which is a big platform with a lot of different hardware which might work or not). With some adjustment it might work well on python, but since uPyEasy is basically an i/o control app it needs access to the IO ports.

For armbian (which is running on Orange Pi's) i have seen a GPIO port for Python, and examples of how it works, so it's likely that it will work on that platform. Also armbian is small enough (with as little interrupts as possible, since interrupts might break the uPyEasy time critical functions). I saw the I2C protocol implemented in armbian, meaning it's a kernel module solving the interrupts problem for i2c.

For a raspberry i'm uncertain if the same GPIO ports exists for Pythion AND if raspberry doesn't interrupt uPyEasy frequently, it might or maybe not. If armbian works on a raspberry, then it's a different story.

LisaM · #27 Post by **LisaM** » 13 Oct 2017, 17:32

alpat59 wrote: ↑13 Oct 2017, 13:40 A really fantastic job, Lisam! Is there some ideas about release date? Also beta version just to test the product will be appreciated. Thank you

Sorry, not yet. The current planning:
- First release will be an alpha release, just to test if the UI is working on several platforms (pyboard, esp32, orange pi, nodemcu). Meaning the network is working to!
- Second alpha release will contain UI + domoticz http/mqtt protocol + gpio control plugin + 1 script (again on same platforms)
- Third alpha release will contain everything from second + i2c + spi + timing (again on same platforms)
- First beta release: ready for playtime!
- First prd after a number of beta's.

Depending on how busy i'm @work and @private, the first alpha release will be in a few weeks.

The bootup sequence:
- If ethernet (adapter + ip address + gateway adress are present) then try to connect and ping the gateway. If it fails: step 2. If adapter is present, but first time bootup: ask for ip address + gateway
- If wifi (adapter + ssid are present) then try to connect and ping the gateway. If it fails: step 3. If adapter is present, but first time bootup: ask for ssid (and password)
- If ethernet nor wifi are successful: return to Python Repl. Using Repl, you can set the ethernet or wifi config parameters by hand. The ESPEasy method of AP and then WiFi are no longer needed.

frank · #28 Post by **frank** » 15 Oct 2017, 09:42

i have orderd an py board and an w5500 so i can test the system

Martinus · #29 Post by **Martinus** » 15 Oct 2017, 11:31

LisaM wrote: ↑13 Oct 2017, 17:32 Sorry, not yet. The current planning:
- First release will be an alpha release, just to test if the UI is working on several platforms (pyboard, esp32, orange pi, nodemcu). Meaning the network is working to!
- Second alpha release will contain UI + domoticz http/mqtt protocol + gpio control plugin + 1 script (again on same platforms)
- Third alpha release will contain everything from second + i2c + spi + timing (again on same platforms)
- First beta release: ready for playtime!
- First prd after a number of beta's.

Hello LisaM

uPyEasy looks like a really great next step to make IOT easy for DIY enthusiasts. It would certainly be nice if the same concept can be used across multiple platforms so people can quite easily migrate from one platform to another!

By the time you are ready to publish a first public release, would you consider to push the source on the Letscontrolit github organization? It would be convenient to have all past, current and future projects stored in a single place on github:
https://github.com/letscontrolit
Please let us know if/when you need access as a contributor.

LisaM · #30 Post by **LisaM** » 15 Oct 2017, 12:04

frank wrote: ↑15 Oct 2017, 09:42 i have orderd an py board and an w5500 so i can test the system

Frank, the W5500 doesn't work in the micropython master branch yet. Use this pull request instead: https://github.com/micropython/micropython/pull/3362

Shardan · #31 Post by **Shardan** » 15 Oct 2017, 12:56

LisaM wrote: ↑15 Oct 2017, 12:04
frank wrote: ↑15 Oct 2017, 09:42 i have orderd an py board and an w5500 so i can test the system
Frank, the W5500 doesn't work in the micropython master branch yet. The W5500 patch is not merged in the master branch yet: https://github.com/micropython/micropython/pull/1859
This fork is working: https://github.com/hjf/micropython

As some people will want to test it would be nice to have a rough list which hardware will be supported.

frank · #32 Post by **frank** » 15 Oct 2017, 13:46

LisaM wrote: ↑15 Oct 2017, 12:04
frank wrote: ↑15 Oct 2017, 09:42 i have orderd an py board and an w5500 so i can test the system
Frank, the W5500 doesn't work in the micropython master branch yet. Use this pull request instead: https://github.com/micropython/micropython/pull/3362

Based on this i orderd the 5500¨

Re: ESP Easy development status
Meld dit bericht Citeer
#118 Bericht door LisaM » 17 Sep 2017, 16:25

frank schreef: ↑17 Sep 2017, 14:47
this looks great LisaM. And a lot of IO. What kind of network shield are you using?
A W5100, but it isn't working properly with the micropython wiznet5k driver so i ordered a W5500.
The used PyBoard: https://www.aliexpress.com/item/STM32F4 ... 29035.html

should i order the 5100????

LisaM · #33 Post by **LisaM** » 15 Oct 2017, 13:51

frank wrote: ↑15 Oct 2017, 13:46 Based on this i orderd the 5500¨

Re: ESP Easy development status
Meld dit bericht Citeer
#118 Bericht door LisaM » 17 Sep 2017, 16:25

frank schreef: ↑17 Sep 2017, 14:47
this looks great LisaM. And a lot of IO. What kind of network shield are you using?
A W5100, but it isn't working properly with the micropython wiznet5k driver so i ordered a W5500.
The used PyBoard: https://www.aliexpress.com/item/STM32F4 ... 29035.html

should i order the 5100????

No, Damien fixed the W5500: https://github.com/micropython/micropython/pull/3362. Use the micropython master branch and apply pull-request 3362 and then it's working.

Code: Select all

make MICROPY_PY_WIZNET5K=1 BOARD=PYBV10

sudo dfu-util --alt 0 -D build-PYBV10/firmware.dfu

screen /dev/ttyACM0

The 5100 is NOT working.
If you bought the official pyboard, then build using PYBV11 since that is likely the newer V1.1 version.

LisaM · #34 Post by **LisaM** » 15 Oct 2017, 14:06

Shardan wrote: ↑15 Oct 2017, 12:56 As some people will want to test it would be nice to have a rough list which hardware will be supported.

The SOC's dev platforms:

PYboard v1.0 + W5500 (Ethernet, W5200 might work also)
ESP32 (WiFi)
NodeMCU (4MB ESP12F: WiFi)
Sonoff Basic (might be trimmed down, due to 1MB mem)

Uncertain so far:

Orange PI (GPIO api?)
Raspberry PI (GPIO api?)

The list of potential SOC's is very long: https://github.com/micropython/micropyt ... ds-Summary
I'm happy if it works on the 4 dev platform boards above.

frank · #35 Post by **frank** » 15 Oct 2017, 16:17

this is what i orderd: STM32F405RGT6 MicroPython Development Board

and an w5500

LisaM · #36 Post by **LisaM** » 15 Oct 2017, 21:39

I'm having a hard-time with the W5500, since it's a minimalistic implementation the asyncio is giving me all kinds of exceptions...

It's connecting to ethernet, but advanced stuff might not be possible.

frank · #37 Post by **frank** » 16 Oct 2017, 06:18

LisaM wrote: ↑15 Oct 2017, 21:39 I'm having a hard-time with the W5500, since it's a minimalistic implementation the asyncio is giving me all kinds of exceptions...
It's connecting to ethernet, but advanced stuff might not be possible.

okay no problem. The w5500 is an cheap part so i will ditch it when it doesn't work an order a new one.
Just let me know what works

LisaM · #38 Post by **LisaM** » 16 Oct 2017, 20:54

The Wiznet driver, for both 5200 and 5500 chipsets, doesn't (yet) support SO_REUSEADDR, non-blocking mode or ioctl (for poll'ing).

Raised issue to get this fixed!

LisaM · #39 Post by **LisaM** » 19 Oct 2017, 00:47

uPyEasy Pyboard up and running, took some uasyncio rework due to W5500 sloppy implementation...

upyeasy pyboard.JPG

ManS-H · #40 Post by **ManS-H** » 19 Oct 2017, 09:21

Nice piece of work LisaM.

adampr1 · #41 Post by **adampr1** » 19 Oct 2017, 10:48

Nice, nice, nice.
Can't wait until support for ESP32 serie.

All best
Adam

LisaM · #42 Post by **LisaM** » 20 Oct 2017, 15:52

After flashing the firmware, and reboot, uPyEasy will attempt to start automatically and fail because the network settings are not done with the message (on your serial terminal connected to the serial port of the SOC):

Code: Select all

>>> Network not available, set network values!

When using ethernet, configure uPyEasy with the command:

Code: Select all

>>> upyeasy.setnet('192.168.178.204', '192.168.178.1', '255.255.255.0', '192.168.178.1')

The first ip address is the ip address uPyEasy (and pyboard) should be using, the second is the gateway address, the third is the netmask and the last one is the dns ip address. The first two parameters are mandatory.

When using wifi, configure uPyEasy with the command:

Code: Select all

>>> upyeasy.setwifi('wifiap', 'ap-password','guests', 'guest-password')

Where the first parameter (wifiap in this example) is the accesspoint for your wifi, the second is the password for your wifi ap, the third is the backup wifi ap and the fourth the backup wifi password. The first two parameters are mandatory.

After this press ctrl-d for reset and uPyEasy should be up and running.

LisaM · #43 Post by **LisaM** » 21 Oct 2017, 01:54

With zero porting effort, the ESP32! I have to admit, even i was suprised that no porting effort was required to make this running...

uPyEasy GUI is now running on linux, pyboard, esp32...

upyeasy esp32JPG.JPG

grovkillen · #44 Post by **grovkillen** » 21 Oct 2017, 06:52

That's great!

toffel969 · #45 Post by **toffel969** » 21 Oct 2017, 09:04

My wife and daughter will travel from begin Nov until mid dec... about time I order some esp32 hardware. So exciting, thanks to your hard work lisam

BertB · #46 Post by **BertB** » 21 Oct 2017, 12:27

This is a realy great development.
But, I wonder how Easy it will be in the end to setup and use.
I also wonder how 'high speed' or 'real time' modules are handled.
And how portable modules will be across the various platforms. Will it be possible to develop a DS1820 module that can be uses on all platforms and if no, how does one cope with the differences.

jakespeed · #47 Post by **jakespeed** » 21 Oct 2017, 12:56

Hey,
very happy to her about this projekt.
But i havent found how to install this on an ESP32.
Is there an Howto or somthing on github ?
Sorry i didn't find what i have to do!

Tanx
Jake

grovkillen · #48 Post by **grovkillen** » 21 Oct 2017, 13:15

Lisa will release this when it is mature enough. She only use this thread to show current status and get feedback.

Shardan · #49 Post by **Shardan** » 21 Oct 2017, 13:25

It's time to get hands on some ESP32 nodeMCUs and chips....

Good job!

BertB · #50 Post by **BertB** » 21 Oct 2017, 13:54

Who is online