Cliff just found some other bulbs based on ESP8266, in this case are not intended to be reprogrammed because there are no RX,TX and GPIO0 exposed. Also in this case, the ESP8266 is on a dedicated PCB as addon.
Posts made by plinioseniore
-
RE: A Lifx like bulb, based on ESP8266. What about those products for DIYers?
-
RE: A Lifx like bulb, based on ESP8266. What about those products for DIYers?
I hope for them that they will reach that production
Mostly is understand if there is a market for those type of "product", from my personal point of view, those are great products. Because into a permanent installation, a proper hardware gives more reliability than hand-made devices. But I don't really know how many people that plays with MySensor, Souliss and similar will go for this way.
-
RE: A Lifx like bulb, based on ESP8266. What about those products for DIYers?
@Yveaux it mostly depends on the volumes, for small batch (lets say 1k) is easier and cheaper to get the module itself.
Authometion is not the only one that is betting on "products for DIYers", Itead Studio is just starting a campaign for his Sonoff & Slampher as leaked that are based on ESP8266.
-
A Lifx like bulb, based on ESP8266. What about those products for DIYers?
Hi,
I've always been addicted to light and contorl of them to match my mood, me and some other friend in souliss have the LYT8266 that's basically a RGBW bulb with an ESP8266 inside.
This is a product designed for the DIY community and I've much interest in this, because it can help community like MySensor, Souliss and others to growth their smarthomes in a more safe and professional way. They (Authometion) didn't get much media coverage and that's why I'm sharing here these type of product, because it can be a good option also for MySensor based networks.
On my side I really hope that there is enough interest in these type of products oriented for the DIY marked, what do you think about?
Regards,
Dario. -
RE: What may looks like a competitor, but isn't, Souliss
Souliss footprints vary on the hardware and the number of interfaces that the gateway has, generally a Gateway fits in 1, 1.5 KBytes of RAM it depends on enabled features. There are also features (like data persistence) that need more than 2 KBytes.
-
RE: What may looks like a competitor, but isn't, Souliss
What about security mentioned by @scalz? I rember that I've read something about, but was based on an external IC to compute encryption and decryption.
In a peer-to-peer network most of the chyper technique are vane, so their a potential risk, but this may be real only if things scale to a really huge number of users, that's unlikely. In Souliss we have introduced a lock-down that protect people that use port-forwarding to be vulnerable from external access, but this has never really be an issue at this time.
-
RE: What may looks like a competitor, but isn't, Souliss
@scalz more option is always better
-
RE: What may looks like a competitor, but isn't, Souliss
@hek nice see RS485 support in MySensor, is it a Gateway to RS485 nodes or you can handle multiple wireless and RS485 at same time with one Gateway?
Just seen the new configuration, looks same approach that we use in Souliss. Isn't C best practice, but have the configuration in the sketch is a great plus. When a year ago we switches to this, we got a lot of more people able to get started in few time without troubles.
-
RE: What may looks like a competitor, but isn't, Souliss
Hi,
as stated before is really a regret that these project haven't merged at the begin where there were no much differences.
Actually MySensor and Souliss are quite different in the approach even if they share a common goal. From what I've learned about MySensor, the network architecture supported in Souliss are far more complex and flexible (including multiple RS485 and wireless) but this comes at a price of a more complex interaction, so that building a binding becomes more complex for Souliss rather than MySensors.
As example, with MySensor you cannot get more than one Ethernet/WiFi nodes and all the others must be RF ones (correct me if I'm wrong!) and this is in contrast with Souliss that allow as many node type as you need, including RF and others.
A big plus of MySensor is the community, is huge and big compared to our one, and likely the support documentation is better and gives people a way to get started easier.
Regards,
Dario. -
RE: Gateway device
Yes the Atmega32U4 and Atmega328 has in the RAM their main problem, in our case we run smoothly in the 2KBytes available because we don't use ASCII in the protocol, but binary only.
Then the board is for as a remote sensor node, running on battery, not a main gateway board.
In any case, the board that you are designing will work nicely also with Souliss.
-
RE: Gateway device
Hi,
just want to share with you some of our progress in a board similar to the one that you are designing.
This is based on Atmega32U4 and has socket for nRF24L01 and ESP8266 and is designed to be battery operated and support Grove connector. The board has mosfet to switch off the sensor while sleeping and keep low the consumption, this should stand a year on battery.
We just received the PCB, picture at the link below,
http://www.souliss.net/2015/06/sensor-battery-board-pcb-arrived.htmlThe schematic and layout are open-source and hope that this board may fit some needs also in the MySensor community
https://github.com/souliss/boards/tree/master/Battery_Operated_Board/Ver1Regards,
Dario. -
RE: Gateway device
Have you considered Grove plugs for sensors? This can give flexibility and a large enough number of sensors at a reasonable price.
-
RE: nRF24 radio reliability
Sure, but be able to clone an IC means that they have a structure and manufacturing equipments, I guess they can found better way to get income.
Dario.
-
RE: nRF24 radio reliability
I cannot image how they can get revenue on a clone of a device that sells for few dollars.
Thanks for the info,
Dario. -
RE: Gateway device
It mostly depends on what you need, as pointed before, my problem wasn't the USART speed it self.
But that I was no longer able to use the transceiver as a buffer, because is the transceiver to decide when send data over the USART, rather SPI as master allow the MCU to decide when get data.This is a problem with ATmega328 that has much less RAM that the transceiver that is attached to, but of course depends also on the average lenght of the frames that you over the air.
Dario.
-
nRF24 radio reliability
Hi,
what's your experience on reliability of those radio? Not directly, but I've experienced that they hangs after some time.
I've found the the nRF24 library continue to run but the radio doesn't report any new data and start to work again after a new init (no need to reset the micro). I don't know if this may depends on manufacturing, because not all radio shows the same behavior.
Thanks,
Dario. -
RE: How data are coded to Controllers
Looks more clear now.
Does the user need to list the devices (light, door, ...) in the Controller, or the Controller can get those directly form the nodes?
From the protocol, I don't see support for multiple architecture or routing, is it?
Thanks,
Dario. -
How data are coded to Controllers
Hi,
probably my question can be easily answered going in detail with documentation and examples, but I would like to collect information and share ideas with the goal of a comparison between MySensors and Souliss (an open source project where I'm involved in). The scope is understand how and if we can build mixed structure with MySensor and Souliss, just because both are great project and together can shine more.
Let go to the question. How data are coded to a Controller? I saw that MySensor has support for a lot of controllers, that's very nice, but how a Controller known what is behind a node and how it control the node it self?
An example makes easy to explain, consider a network with a Gateway and a Node with a simple ON/OFF light. Is the Controller able to fetch from the Node that he owns a light, once he know, is it able to control that light?
Once coding the controller are you manually defining whatever is in your network, or is there a standard? Let say that I want to switch ON my light, all MySensor implementation use the same way to get the result?Hope that my question were clear enough, but I wasn't able to find an answer by self looking at the wiki.
Regards,
Dario. -
RE: Gateway device
Actually there is really no reason to still use AVR, while there are good reason to use Arduino. I mean, ESP8266 is a SoC that contains both MCU and WiFi radio, you can program the MCU directly and run on it what you need.
Actually there is a porting of Arduino (as core of libraries and methods) to the ESP8266 that is very stable and let you run your own code on the module itself, without have an AVR in between. The ESP8266 has also SPI hardware support, that can give you the way to interact to common radio like nRF24 or RFM69, even if some porting will be required to get the goal. Actually we have just ported Souliss and running over ESP8266 and is really working smoothly.
In terms of hardware there is no one good answer, mostly depends on your (and MySensor) architecture. The Souliss architecture support multiple bridge and routers, with RF and RS485 communication, so it makes sense for us to have nodes based on microcontrollers, this keep power usage and complexity low.
But if you have a start architecture (and probably MySensor has, correct me if I'm wrong) it may also make sense to move to OS based devices with an RF radio to join small and cheap microcontroller nodes.I know that design need a full stop, otherwise ideas storm far away from the goal. I'm just here to say that use a WiFi to USART device as transceiver for a 2Kbyte or 8 Kbyte RAM microcontroller is a bad design, and in my opinion non-WiFi RF may have short life in smarthome solutions.
What I saw in the three years running Souliss, is that further you try to automate, more likely you end up into a central point of decision, that is an OS based device. So you likely will be into a native WiFi or Ethernet device and this lead to use those technology widely, this is likely if you cannot run new cables. If you can run cables, RS485 looks still a good solution.
Regards,
Dario. -
What may looks like a competitor, but isn't, Souliss
Hi,
I'm new in this nice community. I'm not a MySensor users, rather I'm involved into another open-source Arduino based project around the Smarthome and IoT worlds, of course I'm not here to cross-promote the project where I'm in.
MySensors and Souliss are similar and different at same time, and is a regret that we didn't merge our project at a earlier stage. I'm here to follow discussion (this is a really big community) and keep good ideas, then hopefully there could be a common point between our projects.
Keep up the good work,
Dario. -
RE: Gateway device
Hi,
this is my first post and I've pointed here by @hek while discussing of MySensor and Souliss (that is a project similar and different at same time from MySensor).
Just yesterday we got Souliss running on ESP8266 thanks to the porting of the Arduino cores on that MCU, this is an option that in my opinion you should take in account. The use of ESP8266 (and generally of all other) as WiFi to USART isn't impressive, I've never been in love with AT commands and I prefer binary communication compared to ASCII, but generally your AVR USART became your bottleneck.
Compared to SPI, USART isn't a master/slave protocol and the communication is driven by the transceiver, this is a really mess. When you use SPI, your low-RAM AVR decide when read data and this allow you to use the RAM of the transceiver as an external buffer, the tranceiver has mostly more RAM than the AVR.
While running over USART, the transceiver send data when want, so you should care on the AVR of buffering and process the frame only once is complete.More, the ESP8266 has multiple firmware release that doesn't provide a consistent behavior, so you end-up with a your own firmware to bridge data to USART. But once you need to program the ESP8266, you are just a step away to load on it the whole code.
Hope that this can help.
Regards,
Dario.