Running in production mode:

[smartcanada]

pi@raspberrypi:~/infinitude $ ./infinitude daemon -m production Using /dev/ttyUSB0 serial interface [Mon Oct 31 11:51:54 2016] [info] Listening at "http://*:3000" Server available at http://127.0.0.1:3000 Mojo::Reactor::EV: Timer failed: Can't call method "emit" on an undefined value at /usr/local/share/perl/5.20.2/Mojo/IOLoop/Stream.pm line 72. Mojo::Reactor::EV: Timer failed: Can't use an undefined value as a symbol refere nce at /usr/local/share/perl/5.20.2/Mojo/Reactor/EV.pm line 34. [Mon Oct 31 12:17:58 2016] [error] Can't use an undefined value as a symbol refe rence at /usr/local/share/perl/5.20.2/Mojo/Reactor/EV.pm line 34.

[bvarner]

I'm having the same issue here on a raspberrypi, following the instructions in the wiki....

Any traction?

It took me several hours to get a max485 wired up in a slave mode on the pi's UART. I've been able to run the readraw.py from the brybus repo, but I don't trust it's output, and I can't really see what's going on in the modbus registers. 😢

[nebulous]

There are multiple things which could be wrong in this scenario, here are a couple things to try:

1. the serial device hasn't been properly reset/initialized. ThePlan™ is to patch Infinitude to aggressively reset on startup, but it doesn't yet do so. Infinitude comes with a utility to dump parsed frame data from a serial device called cardump in the contrib directory. Running it against your serial device will reset the device appropriately and in @bvarner 's case, might be all that's required to log the rs485 network traffic
2. It's possible that the installed version of Mojolicious is subtly incompatible with mine(obtainable with perl -MMojolicious\ 9999). I happen to be running version 6.65 presently without issue.

[bvarner]

@nebulous thanks for the response!

Output of the mojolicious command... Mojolicious version 9999 required--this is only version 5.54.

Yikes!

Using cardump, here's a small log of what I'm sniffing.

Time    From    To  Type    Length  Hex Content
Looking for 214 byte frame in 226 byte buffer
Looking for 75 byte frame in 233 byte buffer
Looking for 238 byte frame in 248 byte buffer
Looking for 187 byte frame in 255 byte buffer
Looking for 159 byte frame in 262 byte buffer
Looking for 249 byte frame in 269 byte buffer
Looking for 64 byte frame in 276 byte buffer
Looking for 1 byte frame in 283 byte buffer
Looking for 32 byte frame in 290 byte buffer
Looking for 1 byte frame in 297 byte buffer
Looking for 15 byte frame in 304 byte buffer
*** Synced stream after 11 shifts ***
--------------WRITE to 40 ------------
Write to table 3, row 5
00 00 00 00 03 12 00 00 00 00 00 78 d1 6c 00
1483039970  20  40  0c  15  00 03 05 00 00 00 00 03 12 00 00 00 00 00 78
1483039970  40  20  06  1   00
--------------WRITE to 40 ------------
Write to table 4, row 3
01 01 01 00 cc 5b 00
1483039970  20  40  0c  7   00 04 03 01 01 01 00
1483039970  40  20  06  1   00
--------------WRITE to 40 ------------
Write to table 4, row 9
00 01 00 00 54 36 00
1483039970  20  40  0c  7   00 04 09 00 01 00 00
Looking for 85 byte frame in 267 byte buffer
Looking for 231 byte frame in 274 byte buffer
Looking for 255 byte frame in 278 byte buffer
Looking for 32 byte frame in 285 byte buffer
Looking for 1 byte frame in 292 byte buffer
Looking for 64 byte frame in 299 byte buffer
Looking for 1 byte frame in 306 byte buffer
Looking for 1 byte frame in 313 byte buffer
*** Synced stream after 8 shifts ***
1483039970  40  20  06  1   00
--------------WRITE to 40 ------------
Write to table 4, row 11
00 00 00 00 7c 36 00
1483039970  20  40  0c  7   00 04 0b 00 00 00 00
1483039970  40  20  06  1   00
--------------WRITE to 40 ------------
Write to table 3, row 7
01 00 00 00 6c 7c 00

Does this look about right? I'm not 100% sure I've got the AB lines on the right pins, but when they're reversed, I don't get any "decent" data off the tty.

[nebulous]

If cardump is syncing, then you can be rather certain that your AB wires are in their proper locations. I am a bit concerned that cardump needed to resync, however. The signal to your adaptor might be noisy. Make sure you are using decent wire (ideally the same wire used to connect the rest of your devices. Several people have had trouble getting a decent signal when using little jumper wires) and that connections are tight.

You may try running infinitude again with potentially better results now that cardump has reset your serial device.

[bvarner]

I've got everything jumpered right now on a prototype board. My signal is coming from a cat6e run from the AB terminals inside my air handler, and I'm using one of the twisted pairs. Honestly, I'm far more suspicious of the non TP bellwire the installers left in place between the thermostat and the air handler.

Question: Does infinitude ever write to the bus, or only 'snoop' in read mode?

[bvarner]

Hah. I had my system in 'checkout' mode.

When I reran cardump, things came right up, and I haven't seen any resync issues.

[bvarner]

ANNNND it works.

cardump did the trick! 👍

[bvarner]

I'm still getting some 404's though, specifically when the front-end is asking for systems, status, notifications, energy, etc.

[nebulous]

neither cardump or infinitude write to the bus presently. I haven't had time to invest in that particular rabbit hole yet. There is some promising work by @acd called Infinitive which attempts to emulate a SAM (https://www.github.com/acd/Infinitive).

[bvarner]

This is so strange.

After a reboot, things were broken again, and cardump is now refusing to sync. I even soldered things up into a bonified protoboard and tried that out.

eventually, while hot-connecting things --- with jumpers! -- things start to work. So strange.

[bvarner]

oh good lord, the tty is the wrong baud rate.