Getting an error #16
Comments
|
Hey there! Thanks for giving this a try. Indeed it seems like the aprontest binary you have outputs in a different format than the one with which I’m testing. Could you paste the output of “aprontest -l” and “aprontest -l -m N” where “N” are all the device ids you see in the first command? I can roll out a fix pretty quickly after I have those! |
|
Hi, Thank you for getting back to me! I was getting nowhere trying to get
my hub to update, have it too hacked up to connect to their servers anymore.
```
[root@flex-dvt ~]# aprontest -l
Found 4 devices in database...
MASTERID | INTERCONNECT | USERNAME
1 | ZIGBEE | LV_Lamp1
2 | ZIGBEE | LV_Lamp2
3 | ZIGBEE | Fireplace-L
4 | ZIGBEE | Fireplace-R
[root@flex-dvt ~]# aprontest -l -m 1
Device has 2 attributes...
LV_Lamp1
ATTRIBUTE | DESCRIPTION | TYPE | MODE | GET |
SET
1 | On_Off | STRING | R/W | ON |
ON
2 | Level | UINT8 | R/W | 0 |
0
[root@flex-dvt ~]# aprontest -l -m 2
Device has 2 attributes...
LV_Lamp2
ATTRIBUTE | DESCRIPTION | TYPE | MODE | GET |
SET
1 | On_Off | STRING | R/W | ON |
ON
2 | Level | UINT8 | R/W | 0 |
10
[root@flex-dvt ~]# aprontest -l -m 3
Device has 2 attributes...
Fireplace-L
ATTRIBUTE | DESCRIPTION | TYPE | MODE | GET |
SET
1 | On_Off | STRING | R/W | ON |
ON
2 | Level | UINT8 | R/W | 254 |
254
[root@flex-dvt ~]# aprontest -l -m 4
Device has 2 attributes...
Fireplace-R
ATTRIBUTE | DESCRIPTION | TYPE | MODE | GET |
SET
1 | On_Off | STRING | R/W | ON |
ON
2 | Level | UINT8 | R/W | 254 |
254
[root@flex-dvt ~]#
```
I am not exactly sure what I need to do once the server is working, will
the devices just show up in HA or do I need to add an integration?
Thankx again for your help!
J
…On Thu, Dec 10, 2020 at 12:45 PM Mike Kaplinskiy ***@***.***> wrote:
Hey there! Thanks for giving this a try. Indeed it seems like the
aprontest binary you have outputs in a different format than the one with
which I’m testing.
Could you paste the output of “aprontest -l” and “aprontest -l -m N” where
“N” are all the device ids you see in the first command? I can roll out a
fix pretty quickly after I have those!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOELA6M43YT6ILURX6NFYK3SUECKVANCNFSM4USF4M5A>
.
|
This comment has been minimized.
This comment has been minimized.
|
Sorry for the duplicate post, just wanted to include formatted aprontest output: |
|
This should be fixed in 0.1.4 - just re-run the installation command and let me know if you find any more issues! |
|
Now I am getting "Segmentation fault" when I try to run it.
…On Sat, Dec 12, 2020 at 11:16 PM Mike Kaplinskiy ***@***.***> wrote:
This should be fixed in 0.1.4 - just re-run the installation command and
let me know if you find any more issues!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOELA6MXBW34SR7GH4NDCJDSUQ53FANCNFSM4USF4M5A>
.
|
|
That's unfortunate - sorry to hear that! Segmentation fault is pretty weird - Do you have any more information before the crash? Does anything get printed in the log file ( If there aren't any logs, if you could get a core dump, that would help. Try running In theory the old firmware should be uninteresting for the actual binary - the binary completely statically linked and isolated from the host filesystem. As part of releasing 0.1.5 I did upgrade rust itself, so maybe that's the cause somehow? |
mikekap
added
bug
|
Sorry, I have been to busy to get back to you sooner. I made progress using my other hub (same firmware ver). No segmentation error now. I need to reinstall it again on the other hub, I think the file is corrupt. FYI this firmware does not support the install command you provided. The SSH is outdated plus TAR does not support the z option. I have to manually import the tar.gz then unzip and untar. Now that it's running I get this in the log; Jan 02 04:07:50.371 INFO init_logger, min_log_level: Info It continues with the loop_encountered_error error over and over. Thankx again for working on this! |
|
hey @jmayes2 - I think you're using something that cuts off the output on the right. Could you try just using |
|
Sorry for the spam, but could you test if this setup script works on your hub? If not, could bother you to try some of these commands so I know what's available? wget --help
curl --help
gzip --help
gunzip --help
tar --help
tree /etc/ssl/ |
|
Good news, I re-transferred the file to my 1st hub and no error, the log shows my devices were discovered and using mqtt monitor in home assistant I see the devices change state but no new devices in HA, is there some configuration I need to do in HA, load an add-on? (I used the prefix 'wink' ) I will get you the install info in a few. Thankx again, J |
|
When I run the new install line I get this... [root@flex-dvt var]# curl -L --cacert /etc/ssl/certs/ca-certificates.crt https:/ curl performs SSL certificate verification by default, using a "bundle" curl performs SSL certificate verification by default, using a "bundle" |
|
[root@flex-dvt var]# wget --help Usage: wget [-c|--continue] [-s|--spider] [-q|--quiet] [-O|--output-document FILE] Retrieve files via HTTP or FTP [root@flex-dvt var]# curl --help Usage: gzip [-cfd] [FILE]... Compress FILEs (or stdin) [root@flex-dvt var]# gunzip -help Usage: gunzip [-cft] [FILE]... Decompress FILEs (or stdin) [root@flex-dvt var]# tar --help Usage: tar -[cxthvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]... Create, extract, or list files from a tar file Operation: [root@flex-dvt var]# tree /etc/ssl/ |
|
Lastly, the 2nd box that was giving me the errors in the log is not actually online with any devices so I think that may have caused the trouble, I have a feeling if I repair it to new devices it will work ok so I think your work is done other then the install. Thankx again for all the hard work! PS, lmk how to get HA to discover the wink MTQQ, if am sure it's just my being a dummy. |
|
For the old box, try this: Please try not to use it anywhere else - the only difference is For the hub that works, you do need to add some configuration on home assistant. Specifically, you need these lines in That will work with the default discovery topic settings on the wink. If you're not using the defaults, you'll need to match the discovery prefix with the one on the wink - just add a |
|
Ok, both hubs working with that install line :) Funny thing, when monitoring mqtt and stopping/starting the your program I would see discovery information then status (repeating). After I did that a few times it stopped sending the discovery info so now that I have the yaml fixed in ha still no devices. I rebooted the hub but still it starts and only sends status. Any thoughts? If I manually set up a light in yaml what would be the topic, I tried brightness but that is not working. |
|
Ok, I duplicated this on both box's. After install I see on the mqtt monitor that when I start the program I get discovery information with '/home/wink/ID' prefix. I use the -t parm and put in 'homeassistant' which then yields '/homeassistantID', there is no '/' between homeassistant and the ID. (Again at this point discovery info is being sent). So I put in '-t homeassistant/' adding the missing slash. Now I get /homeassistant/ID like I should but discovery is no longer sent. As I did on the other box I took the new parms out and it went back to /home/wink/ID but still no discovery is sent, I can't get it to send discovery anymore on either box. Question?, is config information held anywhere else other the the config file in /opt/wink-mqtt-rs/? I can't figure out why it's no longer sending discovery info when I put it back to defaults. |
|
Putting auto discovery aside I am trying to manually add a light to HA via your mqtt, I can set level and turn on/off but status is not returning. This is the YAML I am using,
The mqtt status line looks like this; Can you tell me what I need to put on the state topic lines? Thankx again for all your help, J |
|
Hey @jmayes2 - let me try to answer those:
{
"brightness_command_topic": "home/wink/2/3/set",
"brightness_scale": 255,
"brightness_state_topic": "home/wink/2/status",
"brightness_value_template": "{{value_json.Level}}",
"command_topic": "home/wink/2/3/set",
"name": "Bedroom Fan",
"on_command_type": "brightness",
"payload_off": "0",
"payload_on": "1",
"platform": "mqtt",
"state_topic": "home/wink/2/status",
"state_value_template": "{% if value_json.Level > 0 %}1{% else %}0{% endif %}",
"unique_id": "home/wink//2"
}You're very close in your config, but |
|
Thank you again, that was the template info I needed for the status response. I use the terminal in HA typing mosquitto_sub -u mqtt-username -P mqtt-pwd -v -t '#' to get a running response of all mqtt info, works nicely. Since I use mosquitto, would I still put 'blackberry' to identify the mqtt server in yaml? I have things working well now but there is weirdness you should know about. After I tried putting in "homeassistant/" with the -t parm both of my installs stopped showing discovery, I know it does not make sense since only the config file has any settings but before I did that I was observing the discovery info each time I rebooted the program using mtqq.sh, now it just starts with status responses every 10 secs. Also when I reboot the mqtt broker or HA your program stops and needs to be restarted in the wink. I have reinstalled but no more discovery info is ever sent. Lastly, using a zigbee GE bulb which supports parms 1&2 (state & brt) and using parm 1 as the state message something happens that causes a loop, the bulb works fine with brightness commands but once I send "off" the loop starts which spawns multiple apontest entries in the process list and ends up crashing the bulb. I have to stop the program, kill the extra aprontest process's and reset the bulb (kill power for a few secs) to get it working again. As a workaround I changed state to parm 2 (brt) which works fine as it sends a 0 for off and no loops, this info is just fyi. After the holiday I will put a hub back to before the I used program (I have a backup of the flash and programmer) then run the sequence of events again and take some snapshots of the mqtt data for you to see. In the meantime I am up and running now with many thanks! Happy Holidays, J |
|
That seems like a reasonable command for doing mqtt listens. I think the answer has been staring me in the face a little bit. Are you running two hubs with To try fix it, try changing the |
|
Actually they are two different installs at two different locations. It
was definitely a infinite loop that it was going into though when I was
using start parm 1 for on/off
…On Thu, Dec 24, 2020 at 12:25 AM Mike Kaplinskiy ***@***.***> wrote:
That seems like a reasonable command for doing mqtt listens. blackberry
in the home assistant yaml sounds reasonable - honestly so long as home
assistant sees ANY mqtt traffic, that part is probably not to blame.
I think the answer has been staring me in the face a little bit. Are you
running two hubs with wink-mqtt-rs on both of them, on the same MQTT
server? That will probably result in sporadic "liveness" on each of them
(check /var/log/wink-mqtt-rs.log) - usually one would connect and the
other would be in an infinite retry loop.
To try fix it, try changing the client_id of each hub. Specifically, in
the mqtt connection config, instead of -s mqtt://foo try -s
mqtt://foo?client_id=second-hub or something similar. The default
client_id is wink-mqtt-rs and mqtt doesn't support multiple clients with
the same id.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOELA6KEZI5MZ454QJSXZNLSWLGEDANCNFSM4USF4M5A>
.
|
Trying to use this on a very old software hub and getting this error on the cmd line for each detected device
'WARN async_failure, error: SimpleError { err: "Output does not match regex:'
no records appear to be going out to my broker.
Can I assume this is because of the old firmware (old apontest)
TX, J
The text was updated successfully, but these errors were encountered: