@nick-willis I have the same problem.
Up till now I was doing a simple hack that changed the naming of the sensors to the description field. Would be good to have an option to use just the description for sensors that have them meaningful and usable. I guess that would be a good topic for HA forum of this extension...
@martinhjelmare thanks. I am still not really good at git kung-fu to do it quickly. will try to do the PR when I have some spare time 
Just a FYI if anyone else will stuck trying to enable this. There's no debug print out for the serial connection in pymysensors as it appears. You need to add the debugs in the code on your own.
Here's the diff:
--- mysensors/mysensors.py.orig 2016-11-19 17:51:39.000000000 +0100
+++ mysensors/mysensors.py 2016-11-19 18:27:43.705631204 +0100
@@ -483,6 +483,7 @@
'Error decoding message from gateway, '
'probably received bad byte.')
continue
+ _LOGGER.debug('Received %s', string.rstrip())
self.fill_queue(self.logic, (string,))
self.disconnect() # Disconnect after stop event is set
@@ -492,6 +493,7 @@
return
# Lock to make sure only one thread writes at a time to serial port.
with self.lock:
+ _LOGGER.debug('Sending %s', message.rstrip())
self.serial.write(message.encode())
Is it possible to use this app when using RS485 transport? I have one of these usb (ftdi based) adapters connected with 2 Arduino MEGA on a RS485 bus:
Tried it but I don't see any messages. Connecting serial monitor does show a traffic.
@hek ok. all good now - the ping pong example working. I forgot about the gateway flag.
BTW, checked to see if the GW has any issues without PR 599 but it seems it is still working OK. I have not changed the HW connections so must be some other change.
I am wondering if a node-2-node communication should be working. I have compiled the ping/pong example for RS485 but it appears the nodes are not communicating.
@hek I will try to check if this change did it.
@hek Looks like something has been fixed in regards to altSoftSerial. Today I've pulled latest development and everything works fine. The gateway has no problem finding nodes and all messages reach their destinations.
@karlheinz2000 Are any of your boards using AltSoftSerial instead of HW serial? I was not able to get a reliable connection with software serial library....
@karlheinz2000
Yes. Got it working with this patch. Although not reliably when other board was using the altsoftserial.
There's no difference between Serial GW and Serial GW with RS485 transport. It is just a matter of not using RF transport. So on the serial console side the communication is the same.
@martinhjelmare So unfortunately haven't had much time to spend on getting these logs yet. But one thing is sure. The domoticz mysensors connection works flawlessly. I am able to see all the sensors, all of them are correctly updated in the domoticz on sketch start up, no events are lost (did same test doing quickly switch toggling from the GUI and from the sketch, same tests on HA were often missing the events). So there's got to be some problem with HA module.
So the bottom line - logs are needed
So do I understand correctly that with the above logs setting I should be able to see the serial transmissions in the HA log? I will try to obtain the serial port data with something like this: http://unix.stackexchange.com/questions/12359/how-can-i-monitor-serial-port-traffic but it would be ideal to figure out why these debugs are not there in the first place. Can I make some changes to the module and force the debug (in the python source file)?
@martinhjelmare But then can I have HA do the same stuff it is doing on other lights? https://home-assistant.io/components/light/ ?
@martinhjelmare said:
The device will show in the HA GUI as soon as all required values comes in, but you should send an initial value for each V_TYPE that you want to use, otherwise some functions will probably not work. Check each platform doc for required types, S_TYPE and V_TYPE.
OK, after sending the V_PERCENTAGE it is visible. I have not understood correctly the table presented in the manual. Seems to be obvious now
However I am wondering how to get rid of the dimmer functionality on HA side. It could be done by sending e.g. V_PERCENTAGE == -1. That would tell the HA side the light is not a dimmer and we could get rid of such option for the lights in the front-end.
@martinhjelmare OK thanks. Will make sure to collect these logs next time. Hopefully I will get the console logs shown. Still not sure why I am not seeing them...
@martinhjelmare So do I need to send all 3 values to HA? As shown in the example sketch?
gw.send(lightMsg.set(currentLevel > 0 ? 1 : 0));
gw.send(dimmerMsg.set(currentLevel));
gw.send(rgbMsg.set(rgb));
Or will it be enough to send the lightMsg (that is V_STATUS)? And just as a sidenote - I have briefly checked the sketch in domoticz. It worked and I was able to turn on/off the lights and see the initial status.
@martinhjelmare Thanks for the suggestions.
@martinhjelmare Yes. It actually works for the switches. I have some issues with getting the lights being shown correctly (although sending the initial values, but that's off topic ).
EDIT: to be sure I've copy/pasted these sections from your post. I see mysensors.mysensors debugs and the component debugs. Just no console print outs.
EDIT2: I need to double check it - not sure IF I am seeing any mysensors.mysensors debugs. Will do that in the evening today.
@martinhjelmare yup it is set to true.
Hi
I wanted to try out the lights via mysensors.
So from a switch sketch I've made a conversion to light sketch. The only change I've made is in present function have used S_DIMMER instead of S_BINARY. Other than that I am using the V_STATUS type to send the updates to HA.
So I can see that the persistence file has been populated with the sensors:
{"0": {"children": {}, "battery_level": 0, "protocol_version": "2.0.1-beta", "sketch_name": "SerialGateway", "sketch_version": "0.1", "sensor_id": 0, "type": 18}, "1": {"children": {"22": {"values": {}, "description": "IB_SALON_M_1", "id": 22, "type": 4}, "23": {"values": {}, "description": "IB_SALON_M_2", "id": 23, "type": 4}, "24": {"values": {}, "description": "IB_SALON_M_3", "id": 24, "type": 4}, "25": {"values": {}, "description": "IB_SALON_M_4", "id": 25, "type": 4}, "26": {"values": {"2": "0"}, "description": "IB_SALON_BL_1", "id": 26, "type": 4}, (...) }, "battery_level": 0, "protocol_version": "2.0.1-beta", "sketch_name": "InputBinary1", "sketch_version": null, "sensor_id": 1, "type": 17}}
but I am not getting anything shown in the GUI. Also I can see that the state requests (getting state from the HA when sketch initializes) are timing out.
So how do I get these lights properly populated? Maybe I am not aware of some obvious fact about light component.
on the side note, I have not seen any higher level explanation of the HA design. Is there something that explains its architecture?
Hm, strange but I do not see any mysensors messages shown in the log. I am seeing:
16-09-20 22:05:29 DEBUG (Thread-2) [homeassistant.components.mysensors] InputBinary1 1 69: value_type 2, value = 0
and
16-09-20 22:40:45 INFO (Thread-2) [mysensors.mysensors] Disconnecting from /dev/ttyACM0
but how to observe what is being sent out on the console line?
@martinhjelmare said:
mysensors.mysensors
Ah, so in a nutshell I could easily change logging level for any Python lib that is using logger lib? Is that one for pymysensors lib?
@hek
I will do the schematic once I solve all issues as I am still losing events while connected to Home Assistant. Need to check whether it is because of pymysensors library (Home Assistant side) or if there is still some GW <-> Sensors problem. At this moment my Sensors board has around 48 binary states one can set/read from the controller and at the same time they are changeable via input pins (falling edge toggles the switch).
To give a quick overview of my setup:
2 x (MEGA 2560 + RS485 module)
I have the following connections for each mega+rs485 module:
The A and B lines are connected to each other. (A-A, B-B). And most importantly I am using the above mentioned minor change in the MyTransportRS485.cpp to replace altSoftSerial with Serial1 (https://forum.mysensors.org/topic/1947/rs485-rs232-serial-transport-class-for-mysensors-org/99)
and just if anyone would like to try it here's the config I am using:
// Gateway:
#define MY_RS485
#define MY_RS485_DE_PIN 2
#define MY_RS485_BAUD_RATE 9600
#define MY_GATEWAY_SERIAL
// below not official for getting the Serial1
#define MY_RS485_SERIAL Serial1
// Sensor node
#define MY_DEBUG
#define MY_RS485
#define MY_RS485_DE_PIN 2
#define MY_RS485_BAUD_RATE 9600
// below not official for getting the Serial1
#define MY_RS485_SERIAL Serial1
Hi!
Pardon my ignorance but I was not able to achieve this. How do I see what's happening on the /dev/ttyUSB0 console when pymysensors is using it? Should I enable something specifically in the logger component?
Right now I am using the following setting:
logger:
default: warn
logs:
homeassistant.components.mysensors: info
thanks.
I was able to solve that long initialization problem with removing AltSoftSerial completely and using another Mega board on Serial1 serving as a GW. It looks like the AltSoftSerial on Nano was not working well with Serial1 on Mega.
Strange that although now it works almost instantly, the reading of data from the HA takes longer than before... Not sure what could be causing this.
It looks that these RS485 modules have the resistors already added between A and B cables and +5 and GND so I don't think that could be an issue.
Hi,
I've got a sketch with Button+Relay which can operate independently from the HA (falling edge of button -> toggles relay). The HA can also trigger the change and it is correctly reflected (by switching on/off -> changes relay to on/off). I am also able to read the HA state when the sketch launches so that the state of relay is correctly brought back on sketch startup.
However I am not sure how should I force update of relay status from HA when it misses some events or HA is off while the sketch is still doing its job. In such case until there's a change triggered by Button or from the HA there is a discrepancy of states (actual vs. shown in HA).
Is there a way to check these states when HA is starting up. Also I would like to check it periodically to ensure I am in sync.
Cheers,
Bart
I am confused as to why the child sensor description string is not used for the name of the sensor. I have a board with many push buttons attached and their names in the sketch are meaningful. Is there a way to automatically have them discovered as, e.g.:
friendly_name: Living Room S 1
instead of
friendly_name: InputBinary1 1 58
I would not have to rename them manually.
I am not sure if I am seeing a normal behavior. I don't know if it is expected that the sensor is taking such long time to become visible to the GW. I have recreated the examples from https://www.mysensors.org/build/rs485
The only difference is that I've added SketchInfo for the GW and used Serial1 on MEGA board instead of AltSoftSerial.
The debug on the motion sensor is as follows:
MCO:BGN:INIT NODE,CP=RSNNA--,VER=2.0.1-beta
TSM:INIT
TSM:INIT:TSP OK
TSF:ASID:OK,ID=1
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:NO REPLY
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:NO REPLY
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:NO REPLY
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
TSM:FAILURE
TSM:FAILURE:PDT
TSM:FAILURE:RE-INIT
TSM:INIT
TSM:INIT:TSP OK
TSF:ASID:OK,ID=1
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSF:MSG:FPAR RES,ID=0,D=0
TSF:MSG:FPAR OK,ID=0,D=1
TSM:FPAR:OK
TSM:ID
TSM:ID:OK,ID=1
TSM:UPL
TSF:PING:SEND,TO=0
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
TSF:CHKUPL:FAIL
!TSM:UPL:FAIL
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSF:MSG:FPAR RES,ID=0,D=0
TSF:MSG:FPAR OK,ID=0,D=1
TSM:FPAR:OK
TSM:ID
TSM:ID:OK,ID=1
TSM:UPL
TSF:PING:SEND,TO=0
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
TSF:CHKUPL:FAIL
!TSM:UPL:FAIL
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSF:MSG:FPAR RES,ID=0,D=0
TSF:MSG:FPAR OK,ID=0,D=1
TSM:FPAR:OK
TSM:ID
TSM:ID:OK,ID=1
TSM:UPL
TSF:PING:SEND,TO=0
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
TSF:CHKUPL:FAIL
!TSM:UPL:FAIL
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSF:MSG:FPAR RES,ID=0,D=0
TSF:MSG:FPAR OK,ID=0,D=1
TSM:FPAR:OK
TSM:ID
TSM:ID:OK,ID=1
TSM:UPL
TSF:PING:SEND,TO=0
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
TSF:CHKUPL:FAIL
!TSM:UPL:FAIL
TSM:FPAR
TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSF:MSG:FPAR RES,ID=0,D=0
TSF:MSG:FPAR OK,ID=0,D=1
TSM:FPAR:OK
TSM:ID
TSM:ID:OK,ID=1
TSM:UPL
TSF:PING:SEND,TO=0
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
TSF:MSG:READ,0-0-1,s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSF:MSG:PONG RECV,HP=1
TSF:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
TSF:MSG:SEND,1-1-0-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.0.1-beta
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=11,pt=0,l=13,sg=0,ft=0,st=OK:Motion Sensor
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
TSF:MSG:SEND,1-1-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
MCO:REG:REQ
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
TSF:MSG:READ,0-0-1,s=255,c=3,t=27,pt=1,l=1,sg=0:1
MCO:PIM:NODE REG=1
MCO:BGN:STP
MCO:BGN:INIT OK,ID=1,PAR=0,DIS=1,REG=1
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
0
TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0
I don't know how to obtain debug from the Gateway Serial but as far as the GW messages on the console it looked as follows:
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.0.1-beta
0;255;3;0;11;SerialGateway
0;255;3;0;12;0.1
1;255;3;0;6;0
1;255;3;0;11;Motion Sensor
1;255;3;0;12;1.0
1;1;0;0;1;
1;1;1;0;16;0
1;1;1;0;16;0
1;1;1;0;16;0
1;1;1;0;16;0
1;1;1;0;16;0
As you see it takes a fair amount of time (around 30-40 secs) to obtain the readings from the sensor. This happens each time I reset the sensor node but it works instantly if I reset the GW (i.e. the readings appear instantly after the reset). Is it expected behavior?
@hek OK, thanks for the hint - thought the article is older. Anyway as I am already on it, I will try to prepare something.
BTW, Apart from the SerialGateway (where Serial is obviously not available for the debug), should the Serial work for the debug? Assuming I am using AltSoftSerial or Serial1 for the RS485 I guess it should be possible. However with DEBUG on I was not able to get it to work.
@mfalkvidd I am referring to the code samples from the article I think it would be good to have a well documented working example. Maybe that's just me but I am getting a feeling there's a lot of scattered info about RS485 configuration.
Could you provide details about the MySensor release version this was made on? I was not able to get it running on version 2.0.0. The development branch however worked fine.
So what's with the DE+RE pins on that USB-RS485 converter? Will it even work in this configuration? I do have such converter but so far I've used the arduino as a SerialGateway to connect to RPi.
oh my
it was definitely too late for me to post any comments on the internet...
How about adding the following define to use the Serial1/2 on Mega. I have not tested yet but assuming the AltSoftSerial lib has the same interface/functionality it should work.
#define MY_RS485_SERIAL Serial1
diff --git a/core/MyTransportRS485.cpp b/core/MyTransportRS485.cpp
index 814f721..ea35c9e 100644
--- a/core/MyTransportRS485.cpp
+++ b/core/MyTransportRS485.cpp
@@ -92,7 +92,11 @@ unsigned char _recSender;
unsigned char _recCS;
unsigned char _recCalcCS;
+#if defined(MY_RS485_SERIAL)
+HardwareSerial& _dev = MY_RS485_SERIAL;
+#else
AltSoftSerial _dev;
+#endif
unsigned char _nodeId;
Hi,
Any reason why this lib is not using Serial1 or Serial2 on Arduino Mega 2560 instead of AltSoftSerial?