MyController.org
-
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:
-
Released: 0.0.2-alpha2 with addition of Ethernet-Gateway and MQTT-Gateway support.
Visit https://github.com/mycontroller-org/mycontroller for installation instructions.
-
@diggs Right now there is no way to extract to spread sheet other than extracting from database directly. Kindly propose your requirements in https://github.com/mycontroller-org/mycontroller/issues
-
Anyone tried MyController.org to setup locally? If yes kindly share your experiences ;)
-
Wiki Link: http://www.mycontroller.org/
-
@jkandasa very nice work! As for my experience, I had a bit of trouble getting it started. Somehow, I was under the impression that double-clicking start.bat would automatically start the Java app. It was later that I realized I then need to point my browser to localhost:8443 and log in. Your WIKI is well written, but I somehow missed that step. BTW, I'm using the Ethernet gateway and editing settings was a breeze.
Possible bug to report- Sensors with an ID of 0 (zero) are not auto-detected. I have four nodes with sensor ID's of 0 that I know are sending data but they do not show up on Sensors page or on Action Board.
-
@d-smes thank you to gave a try with MyController.org. Could you please see your log file is there any error? logs/mycontroller.log
-
@jkandasa Yep, error log full of the same sets of errors. Example of one error pair:
2015-09-16 11:41:55,150 WARN [Thread-3] [org.mycontroller.standalone.db.dao.SensorDaoImpl:52] Sensor:[org.mycontroller.standalone.db.tables.Sensor@e7f65f[id=<null>,sensorId=0,type=<null>,messageType=38,name=<null>,updateTime=<null>,status=<null>,lastValue=<null>,unit=<null>,node=org.mycontroller.standalone.db.tables.Node@18dbb32[id=4,name=<null>,version=<null>,updateTime=<null>,type=<null>,mySensorsVersion=<null>,batteryLevel=<null>,eraseEEPROM=<null>,firmware=<null>]]], Sensser Id should be in the range of 1~254 2015-09-16 11:41:55,150 ERROR [Thread-3] [org.mycontroller.standalone.mysensors.MessageMonitorThread:68] RawMessage[NodeId:4,ChildSensorId:0,MessageType:1,Ack:0,SubType:38,PayLoad:4.825] throws exception while processing!, java.lang.NullPointerException: null at org.mycontroller.standalone.mysensors.ProcessRawMessage.recordData(ProcessRawMessage.java:480) ~[mycontroller-standalone-0.0.2-alpha2-single.jar:na] at org.mycontroller.standalone.mysensors.ProcessRawMessage.setSubMessageTypeSelector(ProcessRawMessage.java:449) ~[mycontroller-standalone-0.0.2-alpha2-single.jar:na] at org.mycontroller.standalone.mysensors.ProcessRawMessage.messageTypeSelector(ProcessRawMessage.java:91) ~[mycontroller-standalone-0.0.2-alpha2-single.jar:na] at org.mycontroller.standalone.mysensors.MessageMonitorThread.processRawMessage(MessageMonitorThread.java:60) [mycontroller-standalone-0.0.2-alpha2-single.jar:na] at org.mycontroller.standalone.mysensors.MessageMonitorThread.run(MessageMonitorThread.java:82) [mycontroller-standalone-0.0.2-alpha2-single.jar:na] at java.lang.Thread.run(Unknown Source) [na:1.8.0_60]The clue appears to be "Sensser Id should be in the range of 1~254"
Nodes with multiple sensors show e.g. sensors 1- 11 but not sensor 0.
-
@d-smes My bad it was a mistake, I understand wrongly like, we will not have sensor id 0, should have only from 1~254, now corrected and will allowed 0~254 id,
you have to stop your mycontroller server and replace lib/mycontroller-standalone-0.0.2-alpha2-single.jar with the fix http://www.filedropper.com/mycontroller-standalone-002-alpha2-single
