Posts made by gonzalonal

Please kindly check my contribution in the git issue. Maybe it will help to clarify your issues.

@LastSamurai said in openHAB 2.2 binding:

@gonzalonal said in openHAB 2.2 binding:

Yes, sure. I'll do that to keep track.

By the way, I have RGBW led strip and I am using it with mysensors with no issues. Would you mind telling me what's wrong so I can recreate the scenario?

You can find the issues here. Basically you (I ;)) can't set RGBW nodes to display pure white colors via openhab, dimming is not working (error confirmed by TimO) and most importantly ACK isn't working properly (for me at least). If you can help with any of this (especially the conversion HSB <=> RGBW) you are most welcome.

Yes, sure. I'll do that to keep track.

By the way, I have RGBW led strip and I am using it with mysensors with no issues. Would you mind telling me what's wrong so I can recreate the scenario?

Hi @TimO and @andreacioni.
Back in the day link we discussed about request type of messages being supported by the binding and the complex scenario it created.
Are there any plans to continue developing this feature?

Today brand new setup with fail results.

I have installed a brand new OH2 snapshot build #1047 and the latest relese of the binding available.

I am using just a single node as ethernet gateway. After a couple of minutes the binding stops sending the messages to the node. It logs as it would send them but nothing is really sent out. I have sniffed the connection with wireshark.

Sometimes, while looking the binding debug logs at OH2 console, it hangs and I have to restablish the connection. This last issue seems more related to OH2 itself but maybe something wrong in the binding is causing it. Again, the is not a single clue in the logs about this.

I have just installed the OH2.1 stable release with the latest release of the binding and everything runs great yet.

Anyone with a similar experience?

Hello.

Is there an easy way to send a message from the gateway (or nodo also) to the controller as a log message? That meaning internal message type and I_LOG_MESSAGE.

I am looking for something like:

send(log, "My log message here");

thanks!

@TimO you just need to toggle the DTR line.

Try:
serialPort.setDTR(true);
Thread.sleep(500);
serialPort.open();
serialPort.setDTR(false);

@mfalkvidd actually looking at the code of mysbootloder, it does support STK500 protocol. I haven't test if it really works...maybe it doesn't.

Hi @gohan

@gonzalonal said in Concept: Proxy Node: multi protocol proxy:

Hi @gohan.

Yes I know about protocols, I'm a teco engineer.
That same congestion you talk about, is already present in the current networks we are building. So, I don't believe it's a real limitation.

There are critical task in home automation that needs messages confirmation or to resend (as TCP does), but there are many more, the vast majority, that doesn't need confirmation. Who would bother to lose a humidity reading.

Offcourse. We agree. Those mode critical messages/commands should be send with the ack bit enabled so as to receive delivery confirmation, and if not, to resend.

@wallyllama said in Concept: Proxy Node: multi protocol proxy:

I think most of the problems could be overcome, but they will take time and effort, which would take away from other projects unless a volunteer comes forward. Im not ready for something like this yet, so I should propbably keep my mouth shut.

@gohan said in Concept: Proxy Node: multi protocol proxy:

Right, since this is community driven project it is difficult to put all that effort into it given that developers have their lives like everybody else

Again, we agree. It's just a concept that I would like to share. Nothing else. We all have many things to do in life and in MySensors as well, but I believe talking about this kind of things, slowly builds the idea in our heads, and may be prone to guide the platform development into it or some other great ideas.

What today seems overkill or impossible, tomorrow we'll see.
Thanks for your comments.

Hi @gohan.

Yes I know about protocols, I'm a teco engineer.
That same congestion you talk about, is already present in the current networks we are building. So, I don't believe it's a real limitation.

There are critical task in home automation that needs messages confirmation or to resend (as TCP does), but there are many more, the vast majority, that doesn't need confirmation. Who would bother to lose a humidity reading.

Hi @gohan . Thanks for showing interest on the topic.

It's sure a hard thing to accomplish, but keeping in mind that daughter networks should be kept as small as possible (around 3~5 nodes) and that, for instance, nrf24l01 has its own fifo buffer, and atmegas has it's own uart buffer (for RS485 example) I believe it would be posible. Maybe creating a software fifo queue.

I know we are very hardware limited, but as hardware evolves, this may become a easily doable task. Not sure if it's doable in a atmega328p but for sure in the newer SAMD platform.

Let me know what you think.
Regards!

What happened with this project? Has been abandoned or finished successfully?
Have you tried automatic calibration?

Hi everyone.

The last couple of days I've been thinking in a new concept for our nodes that would enhance flexibility of our networks.

Nowadays we have Gateways and Nodes. The nodes sends messages by air(nrf24l01/RFM69/RFM65) or by wire(RS485) to the gateway and the gateways then translates those messages into another protocol understood by the controller, could be wifi, ethernet, serial.

The proxy gateway/node concept is based upon the idea of having a gateway talking two different languages, as it does now, but choosing what it talks way down (downlink) the network and way up (uplink) to the main gateway.
Nothing better to comprehend and idea than an image:

In the previous figure, the Proxy node would behave as a nrf24l01 gateway with nodes in its daughter network talking RS485. It would be the gateway of its own daughter network.

The idea came up while designing a network where it would have many nodes very close to each other and it seemed overkill having each node with its own wireless link. I believe a better it's better having just one node talking wirelessly to the gateway and all the others piggybacking in a rs485 bus. For example, a huge three piece window with motorized internal blinds and motorized rollershutters on the outside. This setup would need 6 rollershutter nodes, with 6 RF links. Having just on RF link with a RS485 bus for the rest 5 child nodes seems better.

I believe this concept enables unlimited network expansion without physical nor transport layer limitations.

Let me know what you think about it, and if you feel it's doable.
Regards.

Hello everyone.

I am doing some debug tools for mysensors where I am trying to get some statistics about sensors network.
I am doing all this using serial API

At first I was sending I_HEARTBEAR_REQUEST to nodes, and receiving I_HEARTBEAT_RESPONSE. That worked nice.

Now I want to use I_PING and I_PONG. Maybe I misunderstood the beahavior of this messages, but if I send for example, a ping to node 1, (1:0:3:0:24:1), should'nt I receive 1;255;3;0;25;2?

Should'nt the payload be increased by 1 unit?
By now, i don't get any response from nodes.

Thanks, regards

Hi @andreacioni . Thats a great feature.
But for the moment, I think I prefer doing it manually, by rules, because of the way in which I can show my offline nodes in my sitemap and configure custom notifications for them.

For each node, I have a datetime item showing the time of last heartbeat response received. If more than 25' have passed (5 heartbeats request, 1 heartbeat request each 5 mins) without response, I fire up a notification telling that that specific node has gone offline.

So, back to my original question. Is there any way to get Node Ids at the rules engine?

Do you believe we can customize this kind of behavior with the beta feature proposed?

Thanks, regards.

Hi @TimO, @andreacioni.

I am doing some "expert mode" rules where I need to get the NodeId of a specific sensors, or at least, to get all the configured Nodes Ids. Is that possible?

I would like to cron a rule where every X minutes, heartbeat request message is sent to all configured nodes, so as to see wether they are alive or not.

Thanks, regards.

Hi @kalina. Sorry for rebumping this topic with an unrelated concern.

I am interested in the enclosures you've made for this design and for your gateway.
I have finished a design of my own and now I want to design the enclosure, but I have found that is very expensive to have a custom case built for this prototypes boards, specially when dealing with low volumes.

How do you deal with this issue? Have you found a cheap plastic case manufacturer?

Thanks!

Hi everyone. Have there been any developments regarding CAN Bus Controller integration to MySensors Library?
Thanks.

Sorry @tbowmo. I can't find those files in mysensors library. Are those files included or will be included with the release of your GW?

thanks

HI @tbowmo
I am developing a similar GW board with a different SAMD chip.
Just one silly question. Could you point me in the right direction regarding which files are the ones that need to be modified so as to tell the compiler that W5100 will be connected at SERCOM1 and RFM69 at SERCOM2 for example.
Thanks, regards.

Great news to hear @TimO .
I will be testing the binding in a couple of hours. It's really usefull the new RAW messenger things.
Thanks!

Hi @tekka.
I appreaciate your answer and share your opinion.
Lets focus our efforts in other topics.

Hi @hek. I get what you mean, but nevertheless it may be intereting having this feature for non-sleeping nodes, such as those nodes monitoring motion for a security system or many other critical examples.

Don't get me wrong. I know this could also be achieved with the actual mysensors library and some rules in the controller side but it would be nice to have this extra feature.

Hello everyone.
Now that the heartbeat concept is embebbed in mysensors core, what do you think about adding two variables, I_HEARTBEAT_REQUEST and I_HEARTBEAT_RESPONSE?

The way I intend to use them explained below:

I_HEARTBEAT_REQUEST: When a new or already existing node boots up, it sends this message expecting a I_HEARTBEAT_RESPOSE from the controller with a number as payload. This number represents the frequency in minutes at which the node should send a I_HEARTBEAT_RESPONSE to the controller. A '0' as payload means auto-heartbeat feature disabled. Heartbeat should be answered only if explicit I_HEARTBEAT message receive at the node.

We should add at the core of MySensors, maybe at process(), a method checking if the time since last heartbeat response has exceed the defined HEARTRATE.

With this feature, the node will handle the hearbeat on its own. The controller will not need to send I_HEARTBEAT_REQUEST periodically to everynode to check it's status and new nodes will get HEARTBEAT configuration as soon as they bootup.

Let me know what you think.

@Gustafsson

You are missing the opening brackets

Bridge mysensors:bridge-eth:gateway [ ipAddress="192.168.254.228", tcpPort=5003, sendDelay=200 ] {
door frontDoor [ nodeId="102", childId="4" ]
}

Got it!
Thanks for your quick reply @andreacioni

Hi Kalina.
Nice design. Congratulations.

Two questions for you:
1-Have you considered adding RS485 support so as to comply with all the supported GW for MySensors? It would make your desing really complete and extremely flexible and adaptative.
2- Are you willing to share your design files so we can make custom modifications to it?

Thanks!

Hi @TimO .
I have tried the binding and the issue is fixed as you have said.
I have been looking at the logs, and found the following regarding last update feature:

15:52:11.580 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 1;253;1;0;2;1
15:52:11.583 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.581-0300
15:52:11.585 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.584-0300
15:52:11.590 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.588-0300
15:52:11.594 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.592-0300
15:52:11.598 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.597-0300
15:52:11.602 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.601-0300
15:52:11.606 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.604-0300
15:52:11.609 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.608-0300
15:52:11.613 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.611-0300
15:52:11.618 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.616-0300
15:52:11.624 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.622-0300
15:52:11.628 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.626-0300

Is this the expected behavior? It seems to me that we should have only one "Setting last.." for value updated.
Maybe is my setup. Can someone check this.
Thanks!

Hi @TimO.
I am using several bindings in my OH2 setup.
As I am using MyS and OH2 in a productive and sensible environement I could try out how the other bindings behaved. As soon as I detect the error I had to rollback my setup. So I can't really tell is there is a bug with the latest snapshot of OH2 or if it is something more specific of MyS binding.

I am currently using OH2 Beta 3 with no issues.

@TimO I have solved my probles using OH2 Beta3 and the last release of the MyS binding.

It seems that the problem is only reproduced with the last release of OH2 from Cloudbees. At least withe the release 372.

Have you tryed it?

Thanks @TimO . I will try to make a progressive installation and try to figure out what is causing this behavior.

I'll let you know if I find out.
Have you read my previous message?
Regards

@gonzalonal said:

Thanks @TimO. Now I get it.
What do you think about having two gateways, one with NRF radio and the other one with RFM69 radio?

Will the binding support both gateways simultaneusly with no issues?

Another question..Will you support HearbeatRequest for the development branch?

Thanks, regards.

Hello againg.

I have updated my OH2 to latest nightbuild from cloudbees, and also updated to lastest realease of OH2 MyS Binding.

Now, I am facing an issue, that everytime that OH2 starts, it sends out all the items status to its respective node. This is causing, for example, to open my gates, or lowering my rollershutters, even disabling/enabling my alarm system. So I have shutdown OH2 for time being.

Have anyone faced this behavior before?

This is some of the log:

15:41:40.241 [WARN ] [ome.core.thing.internal.ThingManager] - Initializing handler for thing 'mysensors:bridge-ser:gateway' takes more than 5000ms.
15:41:40.272 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.295 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.322 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.335 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.348 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.362 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.375 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.388 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.402 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.545 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Home.items'
15:41:40.671 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.685 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.697 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.710 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.724 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.738 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.755 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.768 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.783 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.806 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;255;3;0;14;Gateway startup complete.
15:41:40.811 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.856 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.871 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.885 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.898 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.914 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.928 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.941 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:41.029 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;3;1;0;0;
15:41:41.110 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:41.288 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;253;1;0;2;
15:41:41.546 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;6;1;0;2;
15:41:41.799 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;252;1;0;24;REFRESH
15:41:42.052 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;254;1;0;2;
15:41:42.307 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;254;1;0;2;
15:41:42.562 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;3;1;0;2;
15:41:42.817 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;253;1;0;2;
15:41:43.073 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;252;1;0;24;REFRESH

I would really appreciate your help.

Thanks @TimO. Now I get it.
What do you think about having two gateways, one with NRF radio and the other one with RFM69 radio?

Will the binding support both gateways simultaneusly with no issues?

Another question..Will you support HearbeatRequest for the development branch?

Thanks, regards.

Hi everyone.

I have built a dimmer node for my home which has its own buttons and can also be controlled over mysensors net. I am using Mysensors 2.00 development branch.

BUT...what happens if, for some reason, the radio module is not present, or its initialization fails, or something else happens, causing mysensors boot to fail. What happens now, is that the program get freeze at startup.

Wouldn't be a good idea, is spite of mysensors failing, to continue with the program? I would like to have the dimmer working with its buttons, despite of the mysensors net state. Maybe the gateway is down, or the node can't find a parent.

There are several example of nodes that should, or would be nice to work as standalone, despite the radio network condition?
Don't you agree?

Maybe this could be optional with some definitions in config files.
Regards!

Hi @TimO . Are you having both gateways connected to same the OH simultaneously?
Any troubles with that? I imagine you should have different radio channels for each gateway, right? like two separate sensors networks.

Hi @tbowmo .

Would you say that the board is ready for production environement? I am planing in ordering one for my home.

Will you share the sketches for the differente gateways configurations?
Thanks, regards.

Hi @tbowmo. Congratulations.

Have you identified what caused the trouble?
Regards!

Hi @TimO
I am having the exact same simtoms. Huge CPU usage with latest binding version.
Let me know if you need me to run some test to get this solved.

Thanks @tbowmo. Now it's all clear.
What tests do you think are remaining in order to have the board fully tested and ready to production environement?
Regards!

Great design @tbowmo. Very interesting indeed.
I have some questions and suggestions if you don't mind.

Will this support the use of the amplified version of the nrf24l01+ (NRF24L01* + PA + LNA). It uses a little more power than the non aplified version so It's even more sensirtive to power supply noise.

EDIT: In the schematic, upper left corner, in the ATSHA204 module it seems you have forgotten to add the SDA pin conection.

EDIT2: Haven't you thought in adding a battery charger module such as the TP4056. It would be nice to have this board woarking as its own UPS. Having the battery connected in the battery connector without something keeping the battery charged doesn't have much sense to me.

Regards!

Hi @tekka ,
Just starting testing beta version and it looks really nice. Thanks for sharing this great tool.
I usually use it to debug mysensors network.

I think I have found a little bug regarding message subtype.
For example, when I choose to send a message using as subtype V_VAR1, it sends out as V_VAR4.
To actually send it as V_VAR1 I have to choose as Subtype V_HVAC_FLOW_STATE.

Can someone try this in their MYSController Beta 1.0.0beta so as to verify if it is only happening to me, or is a funny bug in the beta.

Once againg, thank you very much.
Regards.
Gonzalo

Hi again @TimO .

Just an idea.

What do you think about solving this problematic in this way:

We create a group whose members are all those items that later will populate the binding's memory. I have a group named mysqlpersisted where I put all the items whose data will be stored in my SQL DB. So I could use that group. For this example, let's call it "MemoryGroup"

Then, we can create the following rule:

rule "Populate MySensors binding memory"

when 
System started
then

(maybe add a delay to allow persistance services to load)

MemoryGroup?.members.forEach[i |
        postUpdate(i.name, i.previousState(true))
]

Using this method, memory would get populated everytime OH boots up, with data belonging to the persistance service that we use. And we use postUpdate, so no command is sent to the nodes.

With this I think we solve both problems as data in the binding will be concurrent with the persistance service data.

Let me know what you think about this.

Regards!

Hi @TimO . Good we got in the same page.

I think this topic needs some more thinking.

I was reading OH wiki and found this about receivedCommand.

 Implicit Variables inside the Execution Block

Besides the implicitly available variables for items and commands/states (see the script documentation), rules can have additional pre-defined variables, depending on their triggers:


* Every rule that has at least one command event trigger, will have the variable 
receivedCommand available, which can be used inside the execution block.

* Every rule that has at least one status change event trigger, will have the variable
previousState available, which can be used inside the execution block.

https://github.com/openhab/openhab/wiki/Rules

Maybe this is not available anymore, or at least on OH2.

For now, I think it would be a better approach to use postUpdate at systemStart to populate the binding memory. With this, we'll avoid sending commands to the nodes.

Regards!

I get what you mean @TimO .

Unfortunatelly, using the rule method you suggest would create a lot of traffic (depending on how many sensors you have) at boot up time. Maybe there are some sensors that wouldn't behave the intended way if receiving the "last value" repeteadly.

An example. Lets supose I have an automatic gate, that everytime it receives a command, wether its a "1" or "0" it toggles its moving direction. Like the most common automatic gates remotes.

Gate is closed.

Press button > Gate opens
Press button > (if gate moving) Gate stops
Press button > (if gate open) Gate closes

Now, suppose last command send to the gate made it close. Suddenly, OH restarts itself because of power failure or whatever. It runs the rule to load the memory of the binding, while at the same time it sends to the sensors the last status taken from the persistance service. This would make the gate to open without your notice.

This may create dangerous escenarios.
I hope you can understand what I mean.

Maybe it would be a better idea to handle requests with rules in the way I suggested in the github issue, that is the same way as the OH-1 mysensors serial binding works.

Let me know if I can help in any way.
Regards.

Gonzalo.

Hello @TimO .

Just tested the last build of the binding. Works great.
I see you manage to answer the nodes requests without having to trigger a rule to respond.

I though that wasn't possible due to the limitation of the API. Did they manage to solve this from the OH side?

Does the binding itself keeps track of the items values, or does it querys OH (or its persistence service) for getting the right value?

Thanks!
Gonzalo

Hi @andreacioni. Thanks for your answer.
I have tested your custom build and it's working flawlessly.

09:10:36.913 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete.
09:10:37.161 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;

09:10:37.172 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;2;1.5.3
09:10:37.177 [DEBUG] [s.internal.MySensorsBridgeConnection] - Good,Gateway is up and running! (Ver:1.5.3)

Let me tell you about my hardware configuration. I am running OH2 Beta2 in a Raspberry Pi 2 Model B with an Arduino Nano V3 working as Serial Gateway directly connected to one of Rpi USB ports.

Please, let me know if you need me to some tests or maybe is just my config.
Thanks, regards.

Hi @TimO.
I have just installed the new release and I believe I've found a little bug. I am using Serial Gateway with version 1.5.3

At boot up time, I am getting the followinf error:

03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received

I have read that this new release, request the gateway for its version so as to prove proper start up.

What I have found is that the binding might be asking for the Gateway version al little too soon.

03:07:50.895 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
03:07:50.912 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete.
03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received
03:07:52.647 [DEBUG] [col.serial.MySensorsSerialConnection] - Shutting down serial connection!
03:07:52.659 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Stopping Writer thread
03:07:52.661 [WARN ] [g.mysensors.protocol.MySensorsWriter] - Writer thread interrupted
03:07:52.666 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader thread

I have tested this manually and found that the gateway ONLY answers its version after its startup is finished and the message "0;0;3;0;14;Gateway startup complete." is sent.

When the binding starts, It makes (somehow) the gateway to reboot. So, the gateway runs its setup() method and when it's done, it send the message "0;0;3;0;14;Gateway startup complete"

Let me know if you can reproduce this error. Maybe it's just some problem with my setup, but with the previus version I was having no issues.

Regards!

Great work! Hope to test this soon.
This is a mayor release towards the upcoming new 2.0 MySensors library.
Thanks again.

Hi TimO.

I am trying to do a gw.request from one of my nodes that requires the value of a numeric item from OpenHAB.

Have you tested this? I am unable to make it work.

I have created a rule:

rule "Heart Rate request"
when
	Item Heart_Rate received command
then
if (receivedCommand == "REQUEST")
{
	logInfo( "Heart Rate", "Heart rate request")
	sendCommand(Heart_Rate, Heart_Rate.state);
}
end

Please, let me know if I am doing it the wrong way.
Regards.

Hi Tim0.

I have read all your instructions in the GitHub Repo.
Is there any special reason why you suggest to add things in manual, text way, rather than with the PaperUI?

I have done it with the PaperUI and manually restarting my nodes and everything works just fine.

Let me know what you think.
Regards

@TimO
Great news TimO. Really nice to hear that.
Regarding STOP functionality for the binding, I have read somewhere that the supported commands by OpenHAB, for RollerShutter items, are Up, Down and StopMove. Have yoy tried something like this?

Regards
Gonzalo.

@TimO
Great TimO. Thanks for clarifying this topic.
Regards.
Gonzalo

@andreacioni Hi andreacioni. Same issue with debug mode with me. Thanks for the tip!

@TimO: V_STOP for Rollershutter sensors, is a MySensors binding limitation, or it is not implemented in OH2 yet?

Another thing I've noticed is that every item added, despite being a regular switch or a rollershutter, is is being added as:

Battery Level
mysensors:cover:gateway:Cover_1_0:battery
MySensors Battery Channel

Is this the intended behavior for every node of my sensor, despite having or not a battery?

Regards.
Gonzalo.

@andreacioni said:

This kind of problem (as I've read online) in this release of OH seems to be not only related to this binding. One suggestion that I found is here: https://github.com/openhab/openhab-distro/issues/82 (last comment) or here: https://github.com/openhab/openhab-distro/issues/81

I've tested it without success but I don't know if I've done it right. I've also try to build myself a rfxcom binding (this one use gnu.io) and it has the same issue

hope this help

EDIT: this work for me, run on OSGI console: feature:install openhab-transport-serial and restart OH

Hi @andreacioni.

You saved the day. It worked for me.
Here the steps I did to make it work.

1- Download latest snapshot from https://openhab.ci.cloudbees.com/job/openHAB-Distribution/ (Download offline version)
2- Unzip the file.
3- Run start_debug.sh
4- In console write "feature:install openhab-runtime-compat1x"
5- Ctrl-D to exit/shutdown OpenHAB
6- Once exited, copy MySensors binding to addons folder.
7- Start againg OpenHAB-
8- Thats it. It should work

Remember to copy your serial thing to things folder.
Regards!
Gonzalo

Hi Tim0.
Really nice work with this binding. Huge step forward into a official MySensors OpenHAB binding.

It would be nice to have the repo updated so as to try the new features you have implemented.

Have you had time to check why we are gewtting that error at OpenHAB 2 Beta while trying to install the binding?

Let me know if there is any way in which I can help.
Thanks, regards!

Gonzalo.

Hi everyone. Just to let you know OpenHAB 2.0.0 first BETA release is available. Unfortunatelly Tim0's binding is throwing some errors while OpenHAB tryes to install it.

2016-01-13 13:46:25.314 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/home/pi/OpenHAB2/Downloads/OpenHAB-Beta/addons/org.openhab.binding.mysensors-2.0.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.mysensors [166]
  Unresolved requirement: Import-Package: gnu.io

        at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1245)[8:org.apache.felix.fileinstall:3.5.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1217)[8:org.apache.felix.fileinstall:3.5.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:509)[8:org.apache.felix.fileinstall:3.5.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)[8:org.apache.felix.fileinstall:3.5.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)[8:org.apache.felix.fileinstall:3.5.0]

Let me know Tim0 if I can help you fix this.
Thanks, regards.
Gonzalo.

@Yveaux
Thanks Yveaux. Pointing the sketch path in the right direction made the trick.
Once again, thanks.

Regards.

Hi, Nice job what yoh've done here.
Awkardly, I am not able to compile the sketch. I have download the last version available form github, but when I try to compile it, the IDE hungs about 60% and nothingelse happens. The compiler log looks like this:

Utilizando biblioteca SPI en carpeta: C:\Program Files\Arduino\hardware\arduino\avr\libraries\SPI
Utilizando biblioteca CircularBuffer_Sniff en carpeta: C:\Users\arnalbago\Documents\Arduino\libraries\CircularBuffer_Sniff (legacy)
Utilizando biblioteca RF24-master en carpeta: C:\Users\arnalbago\Documents\Arduino\libraries\RF24-master (legacy)
Utilizando biblioteca RF24_Sniff en carpeta: C:\Users\arnalbago\Documents\Arduino\libraries\RF24_Sniff (legacy)

C:\Program Files\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10604 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\eightanaloginputs -IC:\Program Files\Arduino\hardware\arduino\avr\libraries\SPI -IC:\Users\arnalbago\Documents\Arduino\libraries\CircularBuffer_Sniff -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24-master -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24_Sniff C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\NRF24_sniff.cpp -o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\NRF24_sniff.cpp.o
C:\Program Files\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10604 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\eightanaloginputs -IC:\Program Files\Arduino\hardware\arduino\avr\libraries\SPI -IC:\Users\arnalbago\Documents\Arduino\libraries\CircularBuffer_Sniff -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24-master -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24_Sniff C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24.cpp -o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\SPI\SPI.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24-master\RF24.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24_Sniff\RF24.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\hooks.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\WInterrupts.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_analog.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_digital.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_pulse.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_shift.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\abi.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\CDC.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial0.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial1.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial2.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial3.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HID.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\IPAddress.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\main.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\new.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\Print.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\Stream.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\Tone.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\USBCore.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\WMath.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\WString.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\core.a
C:\Program Files\Arduino\hardware\tools\avr/bin/avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp/NRF24_sniff.cpp.elf C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\NRF24_sniff.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\SPI\SPI.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24-master\RF24.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24_Sniff\RF24.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp/core.a -LC:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp -lm

Does anyone know what could be happening with this?
I would appreciate any help you can provide.

Thanks, regards.

Shouldn't be nice to have this feature directly emebebed in Mysensors library (as the ack request feature)?
I mean, if I send a status request for a sensor through the controller, to ahve the library automaticcaly answer this type of messages.

Hi, is there any way in which I can identify the message type in my incomingMessage function?

void incomingMessage(const MyMessage &message)
{
	**//I need to identify firstly the command type (REQ, SET,PRESENTATION,etc)**
	// if(message.type == C_REQ)
if (message.type == V_LIGHT) // this would be the subtype
	{ 
		if ((message.sensor - StartingChildID)  < noZones)
		{   
			Relays[message.sensor - StartingChildID].relayState = message.getBool();
		}
	}
}

I need to be able to request values at will from nodes. Mainly for debug purposes.

Thanks. Regards

** I think it can also accept serial protocol - or not?**

I believe it doesn't. It would be nice if it can accept serial upload. I would then be called Dual MysBootloader

@jeylites said:

Relays[i].relayState = gw.loadState(i); // retrieve last values from EEPROM
digitalWrite(Relays[i].relayPin, Relays[i].relayState? RELAY_ON:RELAY_OFF); // and set relays accordingly
gw.send(msg[i].set(Relays[i].relayState? true : false)); // make controller aware of last status
gw.present(i, S_LIGHT); // present sensor to gateway
delay(250);

It's my idea, or shouldn't the sensor be presented to the gateway before sending it status?
Thanks! regards.

Hi, let me ask a silly question just to confirm if I understand how this would work.

This gateway would receive Nodes data throght NRF or RF69 and then send it to controller via wifi? The way back would be, receiving controller commands/data via wifi and get to the nodes through NRF or RF69.

Is this right?

Thanks!

@tekka Great Tekka, thanks again. I will try that.
Regards.

Ok, thanks for that.

I finally found my problem.
The Node was sleeping most of the time. In spite of waking up twice per second, it was not enough to enter the uploading mode in the mysbootloader, so the node wasn't answering back to the gateway, nor MYSController.

Now I have a questions

How can I OTA update/upload the firmware of a sleeping node? Should the gateway, or a relay node, send the upload message to the sleeping node as soon as it wakes up for transmiting its data?
I guess that in order to do that, the sleeping node should always wait for an aknowledge or some kind of message after waking up. I mean:

Sleeping node wakes up
Then, it send its data to controller or to relay node
Afterwards, it wait for the controller to acknoledge the data just send, and to tell him (sleeping node) if there is a firmware upgrade for it.
If there's not, go back to sleep. If there is, go to OTA upgrade routine.

Thanks, regards.

Thanks Tekka for replying.

Just another silly question.
How should I compile my sketch to later be uploaded into a MYSBootloader Arduino Nano?
Should I compile for "Arduino Nano" or for "ATMega328 16Mhz MYSBootloader"?

Thanks, regards.

Gonzalo

Hi, I have a similar issue.
Myabe you can post your peoblem in the following thread:
http://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors/209

regards.

Hi,
Nice little board.

Do you know how long does the dallas temp sensor keeps working on?
I ask this because its minumun supply voltage is 3.0V and you are feeding the board exactly with that.
So, what happens when the battery voltage get a bit below 3.0V?

Thanks, regards.

Hi Tekka.
Great software, thanks for sharing.

I 've being doing some tests and found a problem that seems to be related to my own sketches.

When I upload through OTA the TimeReporter sketch, it uploads fine, and I am able to change the firmware afterward for another one.
But when I upload my own sketch, It uploads fine, and works fine, but it stops to answer MYScontroller commands, such as reboot or assing firmware. So I am stuck with that sketch in that node. To flash another sketch in that node, I have to reflash MYSBootloader again via usbASP and later on, upload the desire sketch wit MYSController.

Am I skiping something in my code that allows MYSBootloader to respond to MYSController commands?
Could you please upload the TimeReporter.ino sketch as example of a working sketch with MYSController/MYSBootloader?

Thanks, regards!

Gonzalo

Hi, have you tried increasing the delay after the conversion command is send to the DSs? I have noted this behavior when the very first conversion of the DS is not waited long enought to finish, athts why its returning 85 Cº, wich is the power on state of the scratchpad.
Let me know if you try it.
Gonzalo

FotoFieber, do you know if you can link multiple mqtt gateways to one openhab controller=

Hi.
I need to know if it is possible to have multiple gateways linked to the same controller.
Lets say I have a serial gateway directly connected to my OpenHab controller. May I add a second ethernet MQQT gateway that is outside my local network (port forwarding being done)?
That would allow me, for example, to log in the controller local data, and also data from wherever in the world I have the second gateway.

Thanks, regards.