Open jmayes2 opened 3 years ago
mikekap
commented
3 years ago 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!
jmayes2
commented
3 years ago 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 notifications@github.com 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 https://github.com/mikekap/wink-mqtt-rs/issues/16#issuecomment-742681430, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOELA6M43YT6ILURX6NFYK3SUECKVANCNFSM4USF4M5A .
BobRyan530
commented
3 years ago I'm getting a different error but potentially related. I had a new, unopened, hub I pulled out yesterday and rooted before ever connecting it to the internet. I think I got it updated to the most current release. I setup homeassistant for the first time today and while I'm able to control the device using aprontest I can't seem to control it through MQTT. Attempting to publish a packet to topic 'home/wink/1/set' with payload '{"On_Off": 0}' I'm getting the failure below
Dec 12 02:17:49.453 WARN async_failure, error: SimpleError { err: "Bad attribute type: STRING" }, type: poll_device
Dec 12 02:17:59.380 WARN async_failure, error: SimpleError { err: "Bad attribute type: STRING" }, type: poll_device
Dec 12 02:18:09.540 WARN async_failure, error: SimpleError { err: "Bad attribute type: STRING" }, type: poll_device
[root@flex-dvt ~]# aprontest -u -m 1 -t 1 -v OFF
Update device with master ID 1, setting value OFF for attribute 1
Waiting for 1 callbacks...
Received a myNodeDataCallback from Zigbee
Source: aprontest
Event: RADIO_EVT_NODE_UPDATE
Status: FLX_OK
Node: 1
[root@flex-dvt ~]# aprontest -u -m 1 -t 1 -v ON
Update device with master ID 1, setting value ON for attribute 1
Waiting for 1 callbacks...
Received a myNodeDataCallback from Zigbee
Source: aprontest
Event: RADIO_EVT_NODE_UPDATE
Status: FLX_OK
Node: 1
[root@flex-dvt ~]# aprontest -l
Found 1 devices in database...
MASTERID | INTERCONNECT | USERNAME
1 | ZIGBEE | New HA Dimmable Light
Found 0 master groups in database...
GROUP ID | NAME | RADIO |
Found 0 control groups in database...
GROUP ID | NAME | RADIO |
[root@flex-dvt ~]# aprontest -l -m 1
Gang ID: 0x7ce8f9f9
Manufacturer ID: 0x10dc, Product Number: 0xdfbf
Device is ONLINE, 0 failed tx attempts, 4 seconds since last msg rx'ed, polling period 0 seconds
Device has 14 attributes...
New HA Dimmable Light
ATTRIBUTE | DESCRIPTION | TYPE | MODE | GET | SET
1 | On_Off | STRING | R/W | OFF | OFF
2 | Level | UINT8 | R/W | 254 |
4 | NameSupport | UINT8 | R | 0 |
61440 | ZCLVersion | UINT8 | R | 1 |
61441 | ApplicationVersion | UINT8 | R | 2 |
61442 | StackVersion | UINT8 | R | 2 |
61443 | HWVersion | UINT8 | R | 1 |
61444 | ManufacturerName | STRING | R | GE |
61445 | ModelIdentifier | STRING | R | SoftWhite |
61446 | DateCode | STRING | R | 20150515 |
61447 | PowerSource | UINT8 | R | 1 |
258048 | IdentifyTime | UINT16 | R/W | 0 |
1699842 | ZB_CurrentFileVersion | UINT32 | R | 33554952 |
4294901760 | WK_TransitionTime | UINT16 | R/W | |
EDIT:
version information
[root@flex-dvt ~]# grep 0 /database/cf*
/database/cf_build:00.01
/database/cf_fver2:00.01
/database/cf_fver3:04.01Sorry for the duplicate post, just wanted to include formatted aprontest output:
[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 ~]#This should be fixed in 0.1.4 - just re-run the installation command and let me know if you find any more issues!
jmayes2
commented
3 years ago Now I am getting "Segmentation fault" when I try to run it.
On Sat, Dec 12, 2020 at 11:16 PM Mike Kaplinskiy notifications@github.com 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 https://github.com/mikekap/wink-mqtt-rs/issues/16#issuecomment-743946268, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOELA6MXBW34SR7GH4NDCJDSUQ53FANCNFSM4USF4M5A .
mikekap
commented
3 years ago That's unfortunate - sorry to hear that! Segmentation fault is pretty weird - wink-mqtt-rs doesn't use any unsafe code itself, so it's definitely a head scratcher.
Do you have any more information before the crash? Does anything get printed in the log file (/var/log/wink-mqtt-rs.log) at all? (e.g. INFO init_logger, min_log_level: Info or similar). If you do have some logging, could you try adding -vvv to the command line args (lives at /opt/wink-mqtt-rs/config) to print as much output as it can?
If there aren't any logs, if you could get a core dump, that would help. Try running ulimit -c unlimited before starting wink-mqtt-rs.
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?
jmayes2
commented
3 years ago 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 Jan 02 04:07:50.372 INFO starting, version: 0.1.5 Jan 02 04:07:50.373 INFO opening_client, client_id: wink-mqtt-rs, port: 1883, h$ Jan 02 04:07:50.379 INFO poller_starting, resync_interval: 10000 Jan 02 04:07:50.508 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$ Jan 02 04:07:50.810 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$ Jan 02 04:07:50.884 INFO discovered_device, name: LV_Lamp1, id: 1 Jan 02 04:07:51.037 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$ Jan 02 04:07:51.227 INFO discovered_device, name: LV_Lamp2, id: 2 Jan 02 04:07:51.267 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$ Jan 02 04:07:51.491 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$ Jan 02 04:07:51.498 INFO discovered_device, name: Fireplace-L, id: 3 Jan 02 04:07:51.776 INFO discovered_device, name: Fireplace-R, id: 4 Jan 02 04:07:51.784 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$ Jan 02 04:07:52.029 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$ Jan 02 04:07:52.257 WARN loop_encountered_error, err: Io(Custom { kind: Invalid$
It continues with the loop_encountered_error error over and over.
Thankx again for working on this! J
mikekap
commented
3 years ago hey @jmayes2 - I think you're using something that cuts off the output on the right. Could you try just using cat /var/log/wink-mqtt-rs.log to get the full output?
mikekap
commented
3 years ago Sorry for the spam, but could you test if this setup script works on your hub?
curl -L --cacert /etc/ssl/certs/ca-certificates.crt https://github.com/mikekap/wink-mqtt-rs/releases/latest/download/wink-mqtt-rs.tar.gz | gzip -d | tar -C / -xvf - && /opt/wink-mqtt-rs/setup.shIf 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
jmayes2
commented
3 years ago When I run the new install line I get this...
[root@flex-dvt var]# curl -L --cacert /etc/ssl/certs/ca-certificates.crt https:/ /github.com/mikekap/wink-mqtt-rs/releases/latest/download/wink-mqtt-rs.tar.gz | gzip -d | tar -C / -xvf - && /opt/wink-mqtt-rs/setup.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. gzip: invalid magic tar: short read [root@flex-dvt var]# curl -L --cacert /etc/ssl/certs/ca-certificates.crt https:/ /github.com/mikekap/wink-mqtt-rs/releases/latest/download/wink-mqtt-rs.tar.gz | gzip -d | tar -C / -xvf - && /opt/wink-mqtt-rs/setup.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. gzip: invalid magic tar: short read
jmayes2
commented
3 years ago [root@flex-dvt var]# wget --help BusyBox v1.22.1 (2014-03-26 18:26:55 EDT) multi-call binary.
Usage: wget [-c|--continue] [-s|--spider] [-q|--quiet] [-O|--output-document FILE] [--header 'header: value'] [-Y|--proxy on/off] [-P DIR] [-U|--user-agent AGENT] [-T SEC] URL...
Retrieve files via HTTP or FTP
-s Spider mode - only check file existence
-c Continue retrieval of aborted transfer
-q Quiet
-P DIR Save to DIR (default .)
-T SEC Network read timeout is SEC seconds
-O FILE Save to FILE ('-' for stdout)
-U STR Use STR for User-Agent header
-Y Use proxy ('on' or 'off')[root@flex-dvt var]# curl --help
Usage: curl [options...]
Usage: gzip [-cfd] [FILE]...
Compress FILEs (or stdin)
-d Decompress
-c Write to stdout
-f Force[root@flex-dvt var]# gunzip -help gunzip: invalid option -- 'h' BusyBox v1.22.1 (2014-03-26 18:26:55 EDT) multi-call binary.
Usage: gunzip [-cft] [FILE]...
Decompress FILEs (or stdin)
-c Write to stdout
-f Force
-t Test file integrity[root@flex-dvt var]# tar --help BusyBox v1.22.1 (2014-03-26 18:26:55 EDT) multi-call binary.
Usage: tar -[cxthvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
Create, extract, or list files from a tar file
Operation: c Create x Extract t List f Name of TARFILE ('-' for stdin/out) C Change to DIR before operation v Verbose O Extract to stdout h Follow symlinks exclude File to exclude X File with names to exclude T File with names to include
[root@flex-dvt var]# tree /etc/ssl/ -sh: tree: not found [root@flex-dvt var]#
jmayes2
commented
3 years ago 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.
mikekap
commented
3 years ago For the old box, try this:
curl -k -L --cacert /etc/ssl/certs/ca-certificates.crt https://github.com/mikekap/wink-mqtt-rs/releases/latest/download/wink-mqtt-rs.tar.gz | gzip -d | tar -C / -xvf - && /opt/wink-mqtt-rs/setup.shPlease try not to use it anywhere else - the only difference is -k which will disable the "actually make sure this binary is what I meant to download". Hackers and all could cheat you here.
For the hub that works, you do need to add some configuration on home assistant. Specifically, you need these lines in configuration.yaml: https://github.com/mikekap/raspberrypi/blob/master/home-assistant/configuration.yaml#L33-L36 . broker is the hostname that your mqtt server runs on - if it's the same machine as home assistant, you could try localhost.
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 discovery_prefix to the config above.
jmayes2
commented
3 years ago 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.
jmayes2
commented
3 years ago 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.
jmayes2
commented
3 years ago 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,
payload_off: "OFF" optimistic: false
The mqtt status line looks like this; home/wink/5/status {"level:255,"On_Off":"ON"}
Can you tell me what I need to put on the state topic lines?
Thankx again for all your help, J
mikekap
commented
3 years ago Hey @jmayes2 - let me try to answer those:
mqtt pub --host raspberrypi --topic homeassistant/status --message online (replacing the mqtt host with your own of course).ps aux | grep wink-mqtt-rs - the file is just used as command line arguments. You can read the full descriptions by running /opt/wink-mqtt-rs/wink-mqtt-rs --help. How are you restarting wink-mqtt-rs? Could there be multiple instances running that are colliding with each other? The easiest way to restart safely is to run /etc/rc.d/init.d/wink-mqtt-rs stop and wait a few seconds for the supervisor to start it again.mqtt sub --host raspberrypi --topic 'homeassistant/#' -T. This is what I get when I restart wink-mqtt-rs on the hub:
homeassistant/light/wink_2/config: {"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"}{
"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 wink-mqtt-rs doesn't publish per-attribute status topics (though it could I suppose). Wink is also smart enough to toggle On_Off if you set level to anything above 0, so you don't need to do both.
jmayes2
commented
3 years ago 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
mikekap
commented
3 years ago 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.
jmayes2
commented
3 years ago 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 notifications@github.com 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 https://github.com/mikekap/wink-mqtt-rs/issues/16#issuecomment-750747516, 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