MyController.org
-
Screenshots of MyController.org server.
-
Demo Link: http://demo.mycontroller.org
Authentication: admin/admin
-
@Kurt Yes, it will fill your '?' mark with serial gateway. Right now MyController.org supports only serial gateway.
It will log all the events, you can schedule a timer, alarm and you can upload firmware of your nodes, many other features.
I never own Edison, But I guess you can run MyController.org server in Edison, if it supports Java 1.8, ~30 MB disk space and 40 MB RAM.
-
Great work - That looks fantastic! I'm curious what you envision as the longer term goals for the project? Do you see there being custom programming features (plugins via java, python, etc)? Feature wise, how does it compare with existing automation systems like openhab?
-
@TD22057 Thank you! As you know already MySensors.org is a fantastic project for Open Source world. I would like to thank you MySensors.org the way of giving my contribution back to MyController.org, hence MyController.org born.
Longer term vision: Align with MySensors.org (primary Open Source Controller)
Features: https://github.com/mycontroller-org/mycontroller#available-featuresThere is no plugin concept available. But it has excellent REST API, You can use your own client.
-
Definitely I will support for Ethernet gateway. I'm learning Ethernet gateway.
-
I like how it does graphical reports on all the sensors, straight up on Day 1! Nice!
-
Just gave it a quick test ... Nice! Worked +/- straight our of the box on my Mac. Next up is indeed to test on my Edison as it's very low power which is nice for 24/7 use.
Are you planning MQTT support?
I like your intend to align with MySensors which I interpret as 'focus on supporting MySensor functionality perfectly' rather than trying to also become a controller for other (home automation - zwave, x10, ... ) protocols as well? If your controller focusses on MySensor it could perfectly sync up with another automation controller using something like MQTT (or perhaps REST like you say is already supported)Kurt
-
Just gave it a quick test ... Nice! Worked +/- straight our of the box on my Mac. Next up is indeed to test on my Edison as it's very low power which is nice for 24/7 use.
Are you planning MQTT support?
I like your intend to align with MySensors which I interpret as 'focus on supporting MySensor functionality perfectly' rather than trying to also become a controller for other (home automation - zwave, x10, ... ) protocols as well? If your controller focusses on MySensor it could perfectly sync up with another automation controller using something like MQTT (or perhaps REST like you say is already supported)Kurt
+1 vote for MQTT. I need a controller that can send out events via MQTT messages as they occur so other software can respond to them. REST is great for some things but I don't want to poll the controller to check it's state.
-
@kurt Thank you! Kindly post us status of Edison test.
Right now I do not have any road map to support for other home automatons (like zwave,x10,etc.,). I guess we can do everything with MySensors.org.
@Kurt, @TD22057 I will think about MQTT support for events.. Can you please open new enhancement under https://github.com/mycontroller-org/mycontroller/issues We can discuss further about this feature.
-
+1 vote for MQTT. I need a controller that can send out events via MQTT messages as they occur so other software can respond to them. REST is great for some things but I don't want to poll the controller to check it's state.
then websockets would be best !
@TD22057 said:
+1 vote for MQTT. I need a controller that can send out events via MQTT messages as they occur so other software can respond to them. REST is great for some things but I don't want to poll the controller to check it's state.
z-wave - Vera -> Domoticz
rfx - Domoticz <- MyDomoAtHome <- Imperihome
mysensors -> mysensors-gw -> Domoticz -
then websockets would be best !
@TD22057 said:
+1 vote for MQTT. I need a controller that can send out events via MQTT messages as they occur so other software can respond to them. REST is great for some things but I don't want to poll the controller to check it's state.
@epierre said:
then websockets would be best !
I'm afraid I have to disagree. MQTT gives you decoupling which is huge advantage. You can write lots of simple systems that broadcast information without worrying about where it's going or what's being done with it. And those systems can start up and shut down as they need to or as you try out new things. It allows you to add to and modify your system without touching most of the components. The more I think about it, the more strongly I feel that the best MySensors system is really a gateway/mini-controller that convert the radio messages into MQTT messages and that's it. Then you can have as many "big" controllers as you want to get web interfaces (MyController), programming ability (OpenHab), that can all listen and publish messages. I'm not sure I'm really describing how powerful this is but once you have a system set up this way, it's absolutely fantastic.
I have a bunch of small scripts that read hardware data in my house. Each is custom for it's application which include reading the electric meter, solar panel output, wireless weather station, etc. They each just publish MQTT messages. I wrote them once and have never really touched them since. But I keep playing around with consumers of those messages. I'm experimenting with different databases for persistence, web GUI's for plotting, alerts sent to my phone, etc. Using MQTT means I never need to touch the hardware specific bits when I want to try out something new.
A MySensors gateway is basically the same kind of system to me - define a message format, convert radio messages and publish them, subscribe to "commands" and convert them back to radio messages. Once you have that, you can run as many different "controllers" as you want since each is just sending and receiving messages. Granted all of this is possible now but there are multiple MQTT gateways (one is a client, one is a pseudo-broker), a few scripts that use the serial connection to do the same thing, and they aren't part of the official release. They also can publish numerical messages or put sensor text into them so there isn't an official message API.
Let's say I have a controller that's working well for me. Along comes MyController (which looks fantastic) and I want to try it out. If it used MQTT, I could just start it up and see how it works with my systems and if I want to use it. Controllers that require the serial gateway basically are all or nothing - either they get the serial line or nothing. So I have to install that controller somewhere near my gateway (not always practical), shut down my existing system, try them out, and then make a choice if I want to keep it or not. If all the controllers used MQTT, then I can run as many as I like and use the best parts of each one. Or, each one can be a much smaller collection of loosely coupled parts that each do a single thing really well (plotting, logging, scripting, etc).
Getting off the soap box now... Feel free to ignore my early morning, haven't had my coffee yet, pseudo-ranting... :smile:
-
Created new feature request to support MQTT gateway - https://github.com/mycontroller-org/mycontroller/issues/3
-
@epierre said:
then websockets would be best !
I'm afraid I have to disagree. MQTT gives you decoupling which is huge advantage. You can write lots of simple systems that broadcast information without worrying about where it's going or what's being done with it. And those systems can start up and shut down as they need to or as you try out new things. It allows you to add to and modify your system without touching most of the components. The more I think about it, the more strongly I feel that the best MySensors system is really a gateway/mini-controller that convert the radio messages into MQTT messages and that's it. Then you can have as many "big" controllers as you want to get web interfaces (MyController), programming ability (OpenHab), that can all listen and publish messages. I'm not sure I'm really describing how powerful this is but once you have a system set up this way, it's absolutely fantastic.
I have a bunch of small scripts that read hardware data in my house. Each is custom for it's application which include reading the electric meter, solar panel output, wireless weather station, etc. They each just publish MQTT messages. I wrote them once and have never really touched them since. But I keep playing around with consumers of those messages. I'm experimenting with different databases for persistence, web GUI's for plotting, alerts sent to my phone, etc. Using MQTT means I never need to touch the hardware specific bits when I want to try out something new.
A MySensors gateway is basically the same kind of system to me - define a message format, convert radio messages and publish them, subscribe to "commands" and convert them back to radio messages. Once you have that, you can run as many different "controllers" as you want since each is just sending and receiving messages. Granted all of this is possible now but there are multiple MQTT gateways (one is a client, one is a pseudo-broker), a few scripts that use the serial connection to do the same thing, and they aren't part of the official release. They also can publish numerical messages or put sensor text into them so there isn't an official message API.
Let's say I have a controller that's working well for me. Along comes MyController (which looks fantastic) and I want to try it out. If it used MQTT, I could just start it up and see how it works with my systems and if I want to use it. Controllers that require the serial gateway basically are all or nothing - either they get the serial line or nothing. So I have to install that controller somewhere near my gateway (not always practical), shut down my existing system, try them out, and then make a choice if I want to keep it or not. If all the controllers used MQTT, then I can run as many as I like and use the best parts of each one. Or, each one can be a much smaller collection of loosely coupled parts that each do a single thing really well (plotting, logging, scripting, etc).
Getting off the soap box now... Feel free to ignore my early morning, haven't had my coffee yet, pseudo-ranting... :smile:
@TD22057 said:
@epierre said:
then websockets would be best !
I'm afraid I have to disagree. MQTT gives you decoupling which is huge advantage. You can write lots of simple systems that broadcast information without worrying about where it's going or what's being done with it. And those systems can start up and shut down as they need to or as you try out new things. It allows you to add to and modify your system without touching most of the components. The more I think about it, the more strongly I feel that the best MySensors system is really a gateway/mini-controller that convert the radio messages into MQTT messages and that's it. Then you can have as many "big" controllers as you want to get web interfaces (MyController), programming ability (OpenHab), that can all listen and publish messages. I'm not sure I'm really describing how powerful this is but once you have a system set up this way, it's absolutely fantastic.
Well I disagree also on this for you would send all around your home network informations on devices and any device plugged on it youdon't have enough control on or which is hijacked will gain control of all you home automation... so if using MQTT do it with a PKI or something similar, this has an overhead but it will preserve your future
Getting off the soap box now... Feel free to ignore my early morning, haven't had my coffee yet, pseudo-ranting... :smile:
same for me :smile:
